Deploy a background worker on Voroa

A background worker is a long-running process with no web port — a queue consumer, a message processor, a scheduler, or any job that runs continuously in the background. On Voroa you deploy a worker straight from a GitHub repository, and it stays running around the clock.

Worker vs web service

A web service listens on a port and serves HTTP requests — it has a URL. A worker does not: it has no web address and answers no HTTP requests. It just runs your process continuously.

Use a worker when your code needs to run in the background — for example consuming jobs from a queue, processing a stream, or polling an external system — rather than responding to web requests.

What you need

• A GitHub repository connected to Voroa.
• A start command — the command that launches your long-running process, for example node worker.js, python worker.py, or npm run worker. A worker has no web server to detect automatically, so the start command is required.

Deploy a worker

1. From your dashboard choose New and select Background Worker.
2. Pick your repository and branch.
3. Set the Root directory if your worker lives in a subfolder of the repository (leave it as / for the repository root).
4. Enter your Start command.
5. Choose a compute size for the worker’s memory and CPU.
6. Create. Voroa builds your code and starts the worker.

How Voroa knows your worker is healthy

A worker has no web port to check, so Voroa confirms it is running from the process state itself. After the build finishes, your worker shows Starting, then Live once its process is up and stable. If the process exits or crash-loops right after starting, Voroa marks the deploy Failed to start so you know immediately instead of seeing a false success.

Reading process output

Print progress and errors to standard output. You can follow your worker’s output in its Logs, the same way you would for a web service.

Environment variables

Set any configuration your worker needs — API keys, queue URLs, database connection strings — as environment variables on the worker. You can add them when you create the worker or any time afterward from its Environment tab. Values are stored securely and injected at runtime; Voroa keeps only the variable names for display, never the values. Mark a variable as available at build time if your build needs it. (PORT is managed by the platform and cannot be set.)

Use a custom Dockerfile

By default Voroa detects your language and builds your worker automatically. If your job needs specific system tooling — a database client, a cloud CLI, image libraries, or anything else — choose the Docker runtime and Voroa builds your worker from the Dockerfile in your repository. Install whatever your job needs in the Dockerfile, and it will be available when your worker runs.

If your Dockerfile is not at the repository root, set the Dockerfile path (for example /docker/Dockerfile). With the Docker runtime the start command is optional — your image’s CMD runs unless you override it.

Running a scheduled job inside a worker

If you need a command to run on a schedule rather than continuously, add a Scheduled Task to your worker — see the guide on scheduling a task. The task runs inside your worker’s running container on the schedule you set.

All Voroa services run in Mumbai (IN), and your usage is billed in INR with a GST invoice.