Skip to content
Docs

Daemon Configuration Reference

You declare daemons with the top-level daemons key in vercel.json. The key is an object that maps each daemon name to its configuration:

vercel.json
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "command": ["node", "worker.js"],
      "instances": { "iad1": 2 },
      "resources": { "requests": { "memory": "2Gi" } }
    }
  }
}

A daemon configuration object supports the following fields:

FieldTypeRequired
rootstringYes
entrypointstringYes
instancesRecord<string, number>Yes
commandstring[]No
resourcesobjectNo
livenessProbeLivenessProbeNo
terminationGracePeriodSecondsnumberNo
bindingsServiceBinding[]No

Edgenivo rejects any other field, including service fields such as framework, runtime, and buildCommand.

The keys of the daemons object are daemon names. A daemon name:

  • Contains only lowercase letters, separated by a single _, a double __, or one or more -. For example, worker, email_sender, and celery-beat are valid, and Worker, worker1, and _worker aren't.
  • Is 64 characters or fewer.

Edgenivo pushes each daemon's image to a repository named daemon.<name>, with repeated hyphens collapsed into one. Two names that collapse to the same repository, such as a-b and a--b, fail the build.

Daemon names and service names don't conflict. A project can have a service and a daemon with the same name.

Type: string

Required. The path to the daemon's source directory, relative to vercel.json. The path must stay inside the project.

Edgenivo doesn't publish files under a daemon's root as static assets of your deployment. If the project's output directory is the same directory as a daemon's root, the build fails. Choose a separate output directory.

Type: string

Required. The path to the Dockerfile or Containerfile to build, relative to root. Name the file Dockerfile or Containerfile, optionally with a suffix, such as Dockerfile.worker. The name is case-insensitive. The directory that contains the file is the build context.

Edgenivo passes your deployment's environment variables to the build as build arguments, and builds the image for the Linux amd64 architecture.

Type: Record<string, number>

Required. The number of instances to run in each region, keyed by region ID. Each count is an integer from 0 to 100.

vercel.json
{
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 2, "cdg1": 1 }
    }
  }
}

Edgenivo runs instances only in the regions listed. Set every count to 0 to stop the daemon without removing it. See Scaling a daemon.

Type: string[]

The command and arguments to run in the container, as an array of strings. command replaces the image's ENTRYPOINT and CMD. When you don't set command, Edgenivo runs the image's ENTRYPOINT and CMD. The build fails if the image defines neither and command isn't set.

vercel.json
{
  "daemons": {
    "celery": {
      "root": "backend/",
      "entrypoint": "Dockerfile",
      "command": ["celery", "-A", "app", "worker", "--loglevel=info"],
      "instances": { "iad1": 1 }
    }
  }
}

The array can contain up to 128 items, and each item can be up to 4,096 characters. Edgenivo doesn't run command through a shell. To use shell features such as environment variable expansion, run a shell explicitly, for example ["sh", "-c", "exec node worker.js --id $WORKER_ID"].

Type: object

The compute resources for each instance. resources.requests.memory sets the memory, and Edgenivo allocates CPU based on the memory you choose:

resources.requests.memoryMemoryvCPUs
"1Gi"1 GiB1
"2Gi" (default)2 GiB1
"4Gi"4 GiB2
"8Gi"8 GiB4
vercel.json
{
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 1 },
      "resources": { "requests": { "memory": "4Gi" } }
    }
  }
}

When you set resources, requests and memory are required.

Type: LivenessProbe

An HTTP GET health check that Edgenivo requests periodically to check that the instance is still healthy. A response with an HTTP status from 200 to 399 counts as a success. Read more in Health checks and restarts.

A changed livenessProbe applies to instances started after it deploys; already-running instances keep the probe they started with.

A LivenessProbe object has the following fields:

FieldTypeDefaultDescription
httpGetLivenessHttpGetNoneRequired. The HTTP request Edgenivo sends.
initialDelaySecondsnumber0Seconds to wait after the container starts before the first probe. An integer from 0 to 86400.
periodSecondsnumber10Seconds between probes, measured start to start. An integer from 1 to 86400.
timeoutSecondsnumber1Seconds to wait for a response before the probe counts as a failure. An integer from 1 to 86400.
failureThresholdnumber3Consecutive failures before Edgenivo restarts the container. An integer from 1 to 10.
successThresholdnumber1Accepted by the schema, but the current controller behaves as if the value is 1, so one successful check resets the failure count. An integer from 1 to 10.

A LivenessHttpGet object has the following fields:

FieldTypeDefaultDescription
portnumberNoneRequired. The port Edgenivo connects to. An integer from 1 to 65535. The process must listen on this port inside the container.
pathstring"/"The request path. Must start with /.
hoststringlocalhostThe host to connect to. The probe runs from inside the instance, so it defaults to localhost.
scheme"HTTP" | "HTTPS""HTTP"The scheme Edgenivo uses for the request.
httpHeadersLivenessHttpHeader[]NoneHeaders to add to the request. Each LivenessHttpHeader is an object with string name and value fields. A Host header sets the request's Host.
vercel.json
{
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 1 },
      "livenessProbe": {
        "httpGet": { "port": 1234, "path": "/health" },
        "initialDelaySeconds": 5
      }
    }
  }
}

Type: number

The number of seconds Edgenivo waits after sending SIGTERM before it terminates the instance. The value is an integer from 0 to 3600. The default is 30. A changed value applies to instances started after it deploys; already-running instances keep the grace period they started with.

vercel.json
{
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 1 },
      "terminationGracePeriodSeconds": 50
    }
  }
}

Raise the value when your process needs more time to finish work after SIGTERM. See Graceful shutdown.

Type: ServiceBinding[]

Service bindings that let the daemon call services in the same deployment. Each binding has the same fields as a service binding: type is "service", service names a service in services, format is "url", and env is the environment variable that receives the service's URL.

vercel.json
{
  "services": {
    "api": { "root": "api/", "entrypoint": "main:app" }
  },
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 1 },
      "bindings": [
        { "type": "service", "service": "api", "format": "url", "env": "API_URL" }
      ]
    }
  }
}

A binding can only target a service. Daemons don't receive traffic, so services can't bind to daemons, and a daemon can't bind to another daemon. Each binding in a daemon must use a different env.


Was this helpful?

supported.