Service Settings

A service's Settings tab holds how it is built and run. Save stores the change; it applies on the next deploy, so click Redeploy when you are ready. Variables have their own tab (Environment Variables), and so do domains and ports (Networking).

Name, hostname and ID

• Service Name is shown in the console. Renaming changes nothing that runs.
• Private hostname is the name other services in the project use to reach it, <hostname>.zenavo.internal (Private Networking). Lowercase letters, digits and dashes, starting with a letter. A change applies on the next deploy; update anything that uses the old address.
• Service ID is permanent and never reused: volumes, logs and API routes use it. Copy it from here for the API or the CLI.

Config files

Configs → Open Config Editor mounts files into the container, such as an Nginx config or a JSON settings file, without changing the image. For each file, set:

• Mount path, the file's full path in the container, for example /etc/nginx/conf.d/default.conf.
• Mode, its permissions in octal (0644 by default).
• The content.
• Replace ${VARIABLE} references with the service's variables, to fill in values from Environment Variables when the service deploys, so secrets stay in Variables.

Config files are stored encrypted, like variables, and written to the server as Kubernetes Secrets. They are read-only in the container: to keep files the app changes, use a volume.

Source and build

For services built by Zenavo, the Source and Build sections hold the repository and branch, Root directory, Dockerfile, Auto deploy, Watch paths, Build arguments and zbpack options. See GitHub, Build Plan and Local Directory. A service that runs a Docker image shows the image instead, and has nothing to build.

Startup command

Override what the container runs, without changing the image:

Field	Overrides	Example
Startup Command (ENTRYPOINT)	The image's ENTRYPOINT	docker-entrypoint.sh
Arguments (CMD)	The image's CMD, passed to the entrypoint	npm run start:prod

Leave a field empty for the image's default. Values run directly, not in a shell: quote tokens that contain spaces, and for &&, | or $VARIABLES write sh -c "…", for example sh -c "npx prisma migrate deploy && node server.js".

Health check and crash limit

Health Check decides when a new instance is ready for traffic; see Health Checks.

Automatic Restart After Crashes Attempts is the crash limit: how many times one instance may restart before the service is suspended. -1 (the default) restarts forever; 0 suspends after the first crash. A suspended service sends the Service suspended notification.

Resource limits

By default a service may use as much CPU and memory as the server has. To keep one service from starving the others on the same server, set a limit per instance:

• CPU (m): millicores; 1000 is one core, 500 half a core. A service at its limit is slowed down, not stopped.
• Memory (Mi): mebibytes. A service that goes above it is stopped and restarted (out of memory), which counts toward its crash limit.

Leave a field empty for no limit. Set memory a good margin above what the service normally uses: the service's Usage tab shows it (Metrics).

Replicas

Replicas runs several instances of a service, up to 20, on the project's server. Traffic is spread across the ready instances, and deploys replace them one at a time, so the service keeps serving if one instance crashes or is replaced.

• Replicas run on the same server, so they protect against a crashed process, not against the server going down.
• A service with a volume can't use more than one replica, because the volume can't be shared across instances.
• Each replica has the resource limits above, and its own memory: keep sessions, uploads and caches in a database, Redis or object storage, not in the process.

Suspend and delete

Under Danger Zone:

• Suspend Service stops it; it is unreachable until you Resume Service. Configuration, domains and volumes stay. See Rollbacks & Suspend.
• Delete Service removes it from the project after you type its name. It stops on the next deploy (Deploy all in the project's Settings). Its volumes stay on the server until the project is deleted. Services that depend on it no longer wait for it to start.

In the manifest

The same settings are fields of the service in the project's manifest (Settings → Advanced → Edit JSON, or the API):

{
  "name": "web",
  "hostname": "web",
  "entrypoint": ["docker-entrypoint.sh"],
  "command": ["npm", "run", "start:prod"],
  "configs": [{ "path": "/app/config.json", "content": "{\"apiUrl\": \"${API_URL}\"}", "mode": 420, "envsubst": true }],
  "crash_limit": 5,
  "cpus": 0.5,
  "memory_mb": 512,
  "replicas": 2
}

mode is decimal in JSON (420 is 0644); cpus is in cores.