Worker Containers

A worker container runs background processes — queue consumers, scheduled tasks, data pipelines, or anything that does not serve HTTP traffic directly. Workers are a container type alongside the default HTTP type.

How workers differ from HTTP containers

In short, a worker has the same compute, scaling, env var, and secret features as an HTTP container, but all networking and traffic management features are disabled.

When to use a worker

• Processing messages from a queue (RabbitMQ, SQS, Redis, etc.)
• Running scheduled or periodic tasks
• Background data processing or ETL jobs
• Any long-running process that does not need to receive inbound HTTP requests

Creating a worker

When creating a container, set the type to worker. The type is permanent — it cannot be changed after creation.

With the Reis CLI:

kind: container
handle: my-worker
name: my-worker
type: worker
image: registry.example.com/myorg/worker:latest
regions:
  - helsinki-1
  - virginia-1
workload:
  cpu: "100"           # millicores
  memory: "256"        # MB
scaling:
  replicas: "1"
  max_replicas: "10"
  autoscalingtargetcpu: "70"

Optional port and health check

If your worker exposes a port (e.g. for an internal metrics endpoint or health check), you can configure it:

• Port — The port your worker listens on. If not set, no internal service is created.
• Health check path — An HTTP path that returns a success response when the worker is healthy. Only available if a port is set.

When both are configured, Bahriya uses the health check to determine whether the worker is ready and healthy. If the health check fails repeatedly, the worker is restarted automatically.

If no port is set, Bahriya monitors the worker process directly — if it crashes, it is restarted.

Bootstrap time

Workers support the same bootstrap time setting as HTTP containers. This is the number of seconds Bahriya waits before starting health checks, giving your worker time to initialise. The default is 30 seconds, configurable between 5 and 600 seconds.

Prometheus metrics

Workers can expose a Prometheus-compatible metrics endpoint, even without serving public traffic. Configure a prometheus port and prometheus path in the Observability section, and Bahriya will scrape the endpoint internally from every replica.

This is useful for monitoring queue depth, jobs processed, processing time, and any custom metrics your worker exposes. See Prometheus Metrics for configuration details.

Scaling

Workers support autoscaling based on CPU or memory utilisation, just like HTTP containers. You can set minimum and maximum replica counts and target utilisation percentages.

For queue-based workers, you may prefer to keep autoscaling disabled and set a fixed replica count, then adjust it as your queue depth changes. Alternatively, set a generous max replica count and let CPU-based autoscaling handle bursts.

Billing

Bahriya bills workers per minute. Every runtime period is rounded up to the next whole minute with a 60-second minimum, per region:

• Your configured minimum replicas accrue charges for as long as the worker is running.
• Extra replicas added by the autoscaler are billed per minute while they are running — a 90-second burst is billed for 120 seconds, not a full hour.
• Stopping or terminating a worker stops billing once the pods exit.

The per-CPU-minute and per-MB-minute rates are the same as HTTP containers and cron jobs. See How Billing Works for the full breakdown.