Skip to content
Docs

Background Workers on Edgenivo

Run background jobs on Edgenivo, from sending emails and processing uploads to running continuous queue consumers and durable AI agents. Edgenivo Daemons run workers such as Celery, BullMQ, and Sidekiq alongside your application. Functions, Cron Jobs, Queues, Workflows, and Sandbox support other ways to start and execute background work.

Choose based on what starts the job, whether it needs a continuously running process, and how it should recover from interruptions.

WorkloadUseExample
A worker that continuously retrieves jobsEdgenivo DaemonsRun a Celery worker, BullMQ consumer, or video processing worker with ffmpeg.
Event-driven jobs with retriesEdgenivo QueuesProcess an uploaded document after the request returns. Use Functions for push delivery or Daemons for polling.
Multiple steps, checkpoints, or waitsEdgenivo WorkflowsFulfill an order, wait for an external event, then send a follow-up.
Jobs on a recurring scheduleCron JobsStart a nightly data sync or publish a daily batch of queue messages.
Short tasks after an HTTP responseEdgenivo FunctionsSend analytics or update a cache with waitUntil, or use after() in Next.js.
Isolated execution of untrusted codeEdgenivo SandboxRun an agent-generated script in a separate environment.

These services work together. A cron job can start a workflow, a Function can publish to a queue, and a daemon can consume queued work and run code in a sandbox.

Use Edgenivo Daemons for a process that stays running and pulls work from a queue, workflow engine, or external API. Package your worker and its dependencies in a container using a Dockerfile, then configure its regions and instance counts in your project.

Daemons support workers for Celery, BullMQ, and Sidekiq, as well as custom consumers for Edgenivo Queues, Amazon SQS, Kafka, or Redis. You can keep your worker framework and connect it to its existing broker. Edgenivo manages the worker process; your broker or queue manages job delivery.

Edgenivo restarts daemon instances that exit or crash and forwards their output to runtime logs. During deployments and shutdowns, handle SIGTERM so your worker can finish or release its current job. Store durable state in your queue, a database, or object storage so another instance can resume the work.

During the beta, daemons run in production with manually configured instance counts and ephemeral local storage. Review Daemons limits for supported configurations, quotas, and deployment restrictions, then follow the Daemons quickstart.

Deploy a worker alongside the frontend or backend that creates its jobs. For example, a video application can use this flow:

  1. The browser uploads a video directly to Blob, then a Function publishes a job containing the file's location.
  2. A daemon retrieves the job, processes the video with ffmpeg, and stores the output in Edgenivo Blob.
  3. The worker updates the job's status in a database so the frontend can display the result.

Use Services when your project contains multiple applications, such as a Next.js frontend and a Python API. See Attach daemons to an existing app for project configuration.

For jobs with several steps or long waits, use Workflows to persist progress between steps. For queue consumers, make repeated delivery safe: use an idempotency key or a stored job result to avoid repeating an external action. See Queues delivery semantics and Workflow concepts.

Yes. Edgenivo supports continuous workers with Daemons, event-driven jobs with Queues, scheduled jobs with Cron Jobs, and durable multi-step tasks with Workflows. For a short task that continues after an HTTP response, use waitUntil in a Function or after() in Next.js.

Yes. Edgenivo Daemons keep your configured worker instances running and restart them if they exit or crash. Daemons pull work through outbound connections. Use Functions or Services for inbound application requests. Instances can restart during deployments, so persist job state outside the process and handle shutdown gracefully.

Yes. Package your Celery, BullMQ, or Sidekiq worker in a container and deploy it as a daemon. Connect it to the broker your framework requires, such as Redis or RabbitMQ. The background workers guide includes worker examples and links to migration guides.

It depends on how you run it. Work in a Function, including waitUntil, shares the function's maximum duration. Daemons run continuously instead of using a per-request invocation, subject to their quotas and lifecycle. Workflows can persist progress across invocations and wait for external events. Design long jobs to recover from interruptions.

You can use both. Queues stores and delivers messages; a daemon can poll Queues and process them. Use Queues push delivery when a Function can handle each job within its duration limit. Use a daemon when you need a continuous consumer, a worker framework, or dependencies packaged in a container. See Queues poll mode.

Use after() for work that runs after a response and fits within the function's duration. For work that needs retries or must survive an interrupted request, publish a queue message or start a workflow. Use a daemon for a separate, continuously running worker alongside your Next.js application.

Yes. Cron Jobs call an endpoint in your production deployment on a schedule. That endpoint can perform a task within the function's duration, enqueue work, or start a workflow. Use a workflow when the job needs multiple steps or must wait before continuing.

Yes. Use Workflows for agents that preserve progress and resume after interruptions or human input. Use a daemon to poll for work or process jobs for a hosted agent, and Sandbox for isolated code execution. See Use Edgenivo Daemons with eve agents for examples that combine workers and durable agent sessions.


Was this helpful?

supported.