Networking
Project-private only
No ingress, no hostname, no TLS termination. Workers receive no inbound traffic from outside the cluster and have no attack surface on the public internet.
Worker Containers
Long-running background work, no ingress required
Run queue consumers, application-managed schedulers, and any continuous workload that should not be reachable from the public internet. Same image, environment, and secret model as HTTP containers — just no hostname.
No public exposure by design
Workers run without ingress, TLS certificates, or DNS records. They communicate with the rest of your stack over project-private networking and can reach Memcached, secrets, and the public internet just like any other container — they just cannot be reached from outside.
Same configuration, same operations
Image, registry, environment variables, secrets, resources, and active regions all work identically to HTTP containers. You can move logic between an HTTP container and a worker without rewriting deployment configuration.
Horizontal autoscaling per region
Set a minimum and maximum number of replicas. Each region scales independently based on CPU and memory utilisation, so a queue spike in one region does not affect capacity elsewhere.
Optional in-cluster health checks
Workers don't require an HTTP server, but if yours exposes a health endpoint you can enable in-cluster probes. Bahriya will restart a worker that becomes unresponsive without ever opening that port to the public internet.
Platform features
Built for workers, not bolted on
Every capability you need to run background work reliably across regions, with no extra moving parts.
Scaling
Autoscaling per region
Horizontal Pod Autoscaler runs in each region independently. Configure CPU and memory utilisation targets with min/max replica bounds — capacity follows demand without manual intervention.
Command control
Override entrypoint and args
Point a worker at a specific entrypoint or argument list without rebuilding the image. Use the same image as your HTTP container with a different command to run a queue consumer or scheduled task runner.
Configuration
Env vars and secrets
Plain environment variables for non-sensitive config, encrypted project secrets for credentials and connection strings. Same secret store you use for HTTP containers and cron jobs.
Observability
Logs, events, and metrics
Stream stdout/stderr logs in the console or CLI, view deployment events, and chart CPU and memory utilisation per region. The same observability surface as HTTP containers.
Observability
Prometheus metrics
Workers can expose a Prometheus-compatible metrics endpoint even without serving public traffic. Configure a port and path, and Bahriya scrapes it internally from every replica — giving you the same application-level visibility as HTTP containers.
Billing
Per-minute compute
Pay for the CPU and memory your workers actually request, per minute, per region. Every runtime period is rounded up to the next whole minute with a 60-second minimum. No charge for ingress capacity you don't use — workers don't consume it.
Use cases
What workers are for
The workloads that don't fit an HTTP container — but still need to run continuously.
Queue consumers
Pull messages from RabbitMQ, AWS SQS, or any external queue and process them. Scale the number of workers based on queue depth via CPU utilisation, or run a fixed pool for predictable throughput.
Application-managed schedulers
If your application has its own scheduler (Celery beat, Laravel scheduler, custom cron loop), run it as a worker. Single replica, no autoscaling, kept alive across deploys.
Long-poll integrations
Listen to webhooks via long-poll, subscribe to event streams (Kafka, NATS), or maintain persistent connections to third-party APIs. Workers stay running between events without needing an HTTP entrypoint.
Background processors
Image resizing, document conversion, ML inference, ETL pipelines — anything you trigger from your HTTP layer and want to handle out-of-band. Pair workers with a queue to decouple request latency from processing time.
Workers vs HTTP containers vs cron jobs
HTTP containers serve requests
Continuous, public-facing, ingress + TLS + DNS. Use when external clients need to reach your code.
Workers run continuously
Continuous, no public exposure. Use for queue consumers, schedulers, and long-running background processes.
Cron jobs run on a schedule
Scheduled, ephemeral. Use for nightly batches, periodic clean-ups, and anything that runs to completion at a fixed cadence.
One platform, one mental model
All three types share image, env vars, secrets, resources, regions, and billing. Pick the right shape per workload — Bahriya manages the rest.
Coming Soon
Managed services roadmap
Planned for later in 2026/2027, timeline subject to change.
Volume Storage
Persistent block storage that attaches to your containers. Retain data across restarts and deployments without external storage services.
Valkey
Redis-compatible in-memory data store with persistent snapshots and restore. Session caching, queues, pub/sub, and real-time data — without Redis licensing concerns.
MySQL
Managed relational database with automated backups, point-in-time recovery, and regional deployment. A production-ready RDBMS for structured data and transactional workloads.
PostgreSQL
Managed PostgreSQL with automated backups, point-in-time recovery, and regional deployment. Advanced SQL features, JSONB support, and extensions for modern application workloads.
CouchDB
A globally distributed, multi-region document database with built-in replication. Conflict-free sync across regions for offline-first applications and geo-distributed NoSQL workloads.
S3 Object Storage
S3-compatible object storage for files, media, backups, and static assets. Accessible from your containers or directly via standard S3 APIs and client libraries.
CDN
Global content delivery network for static assets, media, and API acceleration. Edge caching across multiple PoPs with automatic origin pull from your containers or object storage.
RabbitMQ
Managed RabbitMQ for asynchronous messaging between containers. Multi-region clusters, project-private networking, and per-node billing — same operational model as Memcached.
Move background work off your HTTP path
Deploy a worker container in minutes — same image, same configuration, no ingress.