Workers and cron jobs are live on Bahriya
When we launched Bahriya, the platform shipped with one container type: long-running HTTP services. That covers a large class of workloads — APIs, web applications, internal services — but it is not the whole picture. Real applications also need background processors that drain a queue and scheduled jobs that run a task on a clock.
Today, both are live. Worker containers and cron job containers are available now in the console, the API, and the Reis CLI, across every Bahriya region.
Worker containers
A worker container runs background work. It does not serve HTTP traffic, it is not reachable from the internet, and it does not need a hostname, TLS certificate, or DNS routing mode. It is the right container type for queue consumers, message processors, ETL pipelines, and any long-running process that you do not want to expose.
Workers get the same compute, scaling, environment variable, and secrets features as our HTTP containers — and they bill the same way, per minute per region with a 60-second minimum.
What you get with a worker:
- Multi-region deployment — run the same worker across one, two, or every Bahriya region in a single operation
- Autoscaling — scale on CPU or memory, with the same min/max replica controls as HTTP containers
- Secrets and env vars — inject configuration and AES-256 encrypted secrets exactly as you would for an HTTP service
- Optional health checks — expose a port for an internal health endpoint if you want active liveness checking, or let Bahriya watch the process directly
- Bootstrap time — configurable warm-up window before health checks start, so slow-starting workers do not get killed prematurely
Why this matters: until now, if you ran an HTTP API on Bahriya and your background processor lived somewhere else, you were splitting your stack across two platforms. Now you can run the entire application — public API, internal services, and background workers — under one project, one billing account, one set of secrets, and one set of regions.
Cron job containers
A cron job container runs your image on a schedule. The container starts at the scheduled time, runs your task, and exits. Bahriya keeps a history of past runs with their exit codes and logs, so you can see exactly what happened on every execution.
Cron jobs are the right container type for nightly batch processing, periodic cleanups, scheduled exports, database backups, and any workload that runs at a fixed cadence and finishes.
What you get with a cron job:
- Cron expression scheduling — standard 5-field expressions, or shortcuts like
@hourly, @daily, @weekly, @monthly
- A visual schedule builder — pick from common patterns in the console without writing cron syntax, with a human-readable description and the next five fire times shown before you save
- Timezone-aware — set an IANA timezone and the schedule fires in that timezone regardless of which region the job is running in
- Concurrency policy — choose what happens if a previous run is still executing: skip the new run, run in parallel, or replace the previous one
- Run history with logs — every execution shows start time, duration, status, exit code, and a link to its logs
- Run now — trigger an on-demand execution at any time from the console or with
reis container:run
- Suspend and resume — pause a schedule without deleting the cron job; billing stops while suspended
- Per-run limits — configurable backoff, active deadline, and TTL after finished so you control retries, runtime ceilings, and log retention
Cron jobs bill only while they are actually running. A 5-second run is billed for 60 seconds. A 3-minute run is billed for 180 seconds. There is no charge between executions and no charge while a cron job is suspended.
Why we built both
We have spent years watching teams glue together a container platform for their APIs, a separate scheduler for their cron tasks, and a third thing for their background workers — three pieces of infrastructure, three sets of secrets, three sets of regions to keep in sync, and three bills.
That split made sense when each tool was specialised and the integrations were good. It does not make sense when the goal is to ship an application that has a public surface, some background processing, and a few scheduled tasks. That is most applications.
With workers and cron jobs on Bahriya, the entire shape of a typical application now lives on one platform:
- Public traffic on HTTP containers, behind round-robin or geo-routed DNS with TLS and rate limiting
- Background work on worker containers, scaled to match queue depth or CPU load
- Scheduled work on cron job containers, billed only when they actually execute
One project. One set of secrets. One organisation. One bill. Same regions for everything.
What is the same as HTTP containers
Workers and cron jobs are not a separate product line. They are container types alongside HTTP containers, and they share the rest of the platform:
- The same OCI-compliant image format — bring anything you can build with Docker, Podman, Buildpacks, or any other tool
- The same registry credentials, encrypted and project-scoped
- The same secrets store with AES-256 encryption
- The same regions, with the same per-region resource pricing
- The same activity log, so every change is auditable
- The same Reis CLI, the same console, the same API
If you already deploy HTTP containers on Bahriya, deploying a worker or a cron job is the same workflow with a different container type.
Getting started
In the console, head to a project, click Create container, and pick Worker or Cron job as the type. The forms guide you through the fields that apply to each type and hide the ones that do not.
With the Reis CLI, set type: worker or type: cronjob in your container YAML and run reis container:apply. The full schema and examples are in the knowledge base.
Read the full documentation:
If you are not yet on Bahriya, request early access and you can deploy your first HTTP service, worker, and cron job in the same afternoon.
