Configure processes
Add web, worker, cron and job processes to a service, set commands, replicas, resources and health checks, and stop, start or restart a service.
A process is a named way of running a service's image. One service can run a web server, a worker and a nightly job from the same image, each with its own command, resources and scaling.
| Kind | Console label | Runs | Port |
|---|---|---|---|
http | HTTP, "Receives HTTP traffic" | Continuously, behind the service's internal address and its domains | Required, 1 to 65535 |
worker | Worker, "Background processing" | Continuously, with no route from the internet | Optional: an in-cluster TCP port other services in the environment reach at svc-SERVICE_SLUG:PORT |
cron | Cron, "On a schedule" | At each tick of a five-field schedule, evaluated in UTC | None |
job | Job, "Runs to completion" | Once per release, to completion | None |
Before you begin
- You need the
deployerrole. - Settings in a process's Edit… dialog belong to the service: they save at once, apply in every environment, and reach running instances only with the next release. The release that runs now keeps its frozen configuration.
- Replicas and Instance size under Scaling are per environment. They are staged as a change set and take effect when you deploy it.
- A service with a
nebula.tomlcan set any of these in the file. A setting the file sets is read-only in the console and carries a file badge; see Configure a service from its repository.
Add a process
Select the service on the canvas, then the Settings tab.
Under Processes, select + Add process.
Enter a Name and choose the Kind. Set the Port for an HTTP process, an optional Port for a worker, or the Schedule for a cron process. Set Replicas. Select Add process.
The process appears in the list with its command and its kind, and with its address svc-SERVICE_SLUG:PORT if it has a port. It runs from the next release.
A service needs at least one process: the Delete button is hidden on the last one. A reverse-proxy service has no + Add process button.
Set the start command
- Next to the process, select Edit….
- Under Start command, the dialog shows the image's own command, read from the newest release's image. Before the first release it reads "Deploy once to see the image's start command."
- Set Override to Custom. Enter the Arguments: they run under the image's entrypoint, and the dialog shows the full line as "Runs as: …". Words split on spaces, and quotes keep a phrase together.
- Tick Replace the entrypoint too to replace the entrypoint and
CMDentirely. The field is then named Command. - Select Save process.
Set Override back to Image default to clear the command.
Set replicas and instance size for an environment
- On the Settings tab, find Scaling.
- Use the Replicas stepper to set the number of instances, from 0 to 50. A service with several processes shows one stepper per process, named Replicas · PROCESS. Cron and job processes have none.
- Under Instance size, choose S (0.5 vCPU, 512 MiB), M (1 vCPU, 1 GiB), L (2 vCPU, 4 GiB), XL (4 vCPU, 8 GiB) or Custom. A preset sets request and limit to the same value. Custom takes 0.25 to 32 vCPU and 0.25 to 128 GiB per replica.
- Select Deploy N changes in the bar at the foot of the sheet, or Request approval in a protected environment. Review the change and confirm.
The description under each stepper names the default the environment overrides. The default itself is the Default replicas, Default CPU request, Default CPU limit, Default memory request and Default memory limit fields of Edit…. They accept quantities such as 0.25 for CPU and 256 MiB for memory. The request may not exceed the limit.
A cluster with no node large enough for a replica leaves its deployment waiting with the capacity blocker. The Custom size shows how many nodes can fit one replica.
Set health checks and deployment timing
In Edit…, an HTTP process has three path fields. Every field takes an absolute path such as /healthz.
| Field | What it does |
|---|---|
| Readiness path | Instances receive traffic only while Kubernetes' readiness probe on this path passes. While a release qualifies, the agent also requests the path through the release's own service, and a status below 500 passes that check. Unset, the check requests /. |
| Startup path | A Kubernetes startup probe: the other probes wait until it succeeds. Unset, no startup probe runs. |
| Liveness path | Stored, but no liveness probe runs in 0.39.0. |
A release that never passes the readiness check within 5 minutes fails with the readiness blocker. A worker with a port is checked by a TCP connection to that port instead, and takes no path.
Two numbers shape a deployment:
- Stabilization seconds (default 10): every instance of the primary process must stay ready this long before the release takes traffic.
- Drain seconds (default 30): how long the previous release keeps running after the new one takes traffic. It is also the grace period an instance gets to shut down.
See Deployments for the stages and Deployment states for each blocker.
Run a process as another user
In Edit…, set Run as user to a numeric UID. Leave it blank to keep what is set now: a blank field cannot clear a stored value. The default is a non-root user; 0 runs the process as root.
Stop and start a service in an environment
Stopping scales every process of the service to zero in one environment and withdraws its domains. The release, variables and volumes stay. It starts no deployment and needs no approval, in production too.
Open the environment and either right-click the service and select Stop in ENVIRONMENT…, or open the service's Settings tab and select Stop in ENVIRONMENT at the foot.
Confirm Stop in ENVIRONMENT. The service's status reads Stopped.
To bring it back, select Start in ENVIRONMENT in the same places. Each process returns to its configured replica count and the domains return.
A service you scaled to 0 by hand reads Scaled to 0, not Stopped.
Restart instances
A restart rolls the instances of the live release one at a time, so the service keeps serving. The release and its configuration do not change.
- Whole service: select More actions for SERVICE on the service's sheet, then Restart, or right-click the service and select Restart. Confirm Restart. The action is disabled when nothing is live.
- One instance: open the Instances tab and select Restart on its row. The row shows Restarting while the request runs, and the replacement instance appears as a new row.
The Instances tab lists each instance with its node, status, restart count, CPU and memory. Database services show Data and Backups tabs instead, and Postgres databases also show Replicas.
Delete a process
Deleting a process removes it from the service in every environment, together with its domains, its volume definitions and any mesh grants that target it. Releases that run now keep it until their next deployment.
Next to the process, select Delete, then confirm Delete process.
Set processes in a nebula.toml
[processes.web]
kind = "http"
cmd = "node server.js"
port = 8080
replicas = 2
cpu = "500m"
memory = { request = "256Mi", limit = "512Mi" }
stabilization_seconds = 20
drain_seconds = 30
[processes.web.checks]
startup = "/healthz"
readiness = "/ready"
[processes.worker]
cmd = "node worker.js"
[processes.nightly]
kind = "cron"
schedule = "0 3 * * *"
cmd = "node jobs/cleanup.js"
[environments.production.processes.web]
replicas = 4A new process with no kind, schedule, port or checks, like worker, is created as a worker. The overlay under [environments.production.processes.web] sets the replicas only in production. Every key is described in the nebula.toml reference.
Verify
Open the Deployments tab and follow the new release until it reads Healthy. Then open the Instances tab: each instance shows Running with its node. A process that fails its checks shows the blocker on the deployment; see Deployments troubleshooting.
Next steps
- Release commands and files: run a migration before the new release starts.
- Add a volume: give a process persistent storage.
- Add a custom domain: route traffic to an HTTP process.
- Read logs and metrics: see what each instance prints.
Set variables and references
Set variables for a service, an environment or a whole project, point one value at another service with ${{ }}, and generate secrets.
Run release commands and mount files
Run a command such as a database migration before each release starts, and mount a service's variables as read-only files.