HTTP Containers
HTTP containers are long-running services that accept incoming HTTP traffic. Use them for APIs, web apps, dashboards, and anything that listens on a port and serves requests.
When you deploy an HTTP container, Bahriya gives you:
- A public hostname with automatically provisioned TLS
- Optional custom domains (CNAME or A record)
- Autoscaling based on CPU or memory utilisation
- Rate limiting per IP (requests-per-minute and requests-per-hour)
- IP allow-list and IP deny-list
- HTTP basic authentication
You configure the container image, environment variables, secrets, CPU and memory, and the regions to run in. Bahriya handles everything else.
When to use
Choose an HTTP container if you need any of the following:
- Serve HTTP traffic from the public internet
- A predictable hostname for clients to call
- Built-in TLS, rate limiting, or basic auth without writing application code
- Autoscaling between a minimum and maximum number of replicas
- A health check that decides when a new deployment is ready to serve traffic
How it differs from Workers and Cron Jobs
- HTTP containers run continuously and serve HTTP traffic. They get a hostname and ingress.
- Workers run continuously without any public exposure. Use them for queue consumers, schedulers your application manages, and background processes.
- Cron Jobs run on a schedule, complete, and exit. Use them for nightly batches, periodic clean-ups, and scheduled exports.
Required configuration
| Field | Description |
|---|
| Name | A human-readable label. |
| Handle | A unique lowercase identifier — used in hostnames and is immutable after creation. |
| Image | The full container image reference including tag. |
| Container port | The port your application listens on (defaults to 8080). |
| Health check path | An HTTP path that returns 2xx when the container is ready (defaults to /healthz). |
| Min CPU / memory | Guaranteed resources for the container. |
| Regions | One or more regions to run in. |
See the Containers overview for the full field reference.
Hostnames
Every HTTP container gets a system-generated hostname per region (for example my-api.helsinki-1.x.on.bahriya.app). You can also configure:
- A vanity hostname on a Bahriya-owned domain
- A custom hostname on a domain you own (point a CNAME at the provided target)
TLS certificates are provisioned automatically and renewed before expiry.
Autoscaling
Set a minimum and maximum replica count, and Bahriya will scale the container between them based on CPU and memory utilisation targets. Scaling is per region.
Security knobs
- Basic auth — protect the container with up to 10 username/password credentials. Passwords are encrypted at rest.
- Rate limiting — cap the requests per minute and per hour per source IP.
- IP allow-list / deny-list — allow or deny IPs and CIDR ranges.
Prometheus metrics
If your application exposes a Prometheus-compatible metrics endpoint, you can configure a prometheus port and prometheus path in the Observability section. Bahriya will scrape the endpoint from every replica and display the metrics in the console.
See Prometheus Metrics for configuration details.
Restart and terminate
You can restart an HTTP container at any time. Restarting triggers a rolling redeploy of the pods, picking up any pending image or configuration changes.
Billing
Bahriya bills HTTP containers 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 container 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 container stops billing once the pods exit.
See How Billing Works for the full breakdown.
