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

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.

Gateway logs

Every request to an HTTP container is recorded as a structured gateway log entry, available in the Observability section of the container detail page. Each entry includes the timestamp, HTTP method, response status, host, path, end-to-end latency (with a gateway/upstream breakdown on hover), client IP, and the region that served the request.

You can filter by time range (15 minutes up to 24 hours), pick how many lines to load (50 to 500), and turn on auto-refresh (5–60 seconds) to follow live traffic. Gateway logs sit in front of your container, so they capture requests that were rate-limited, IP-blocked, or rejected by basic auth — even when those never reach your application.

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.