Containers
A container is a running instance of an OCI-compliant container image deployed and managed by Bahriya. It is the primary resource you interact with — configuring it tells Bahriya what to run, where to run it, and how to expose it.
Required configuration
| Field | Description |
|---|
| Name | A human-readable label (e.g. My API). |
| Handle | A unique, immutable, lowercase identifier (e.g. my-api). Used in hostnames and pipeline names. |
| Image | The full container image reference including tag (e.g. nginx:latest, ghcr.io/myorg/myapp:v1.2.3). Any OCI-compliant image is supported. |
| Registry | The private registry to pull the image from (if the image is not public). |
| Container port | The port your application listens on inside the container (e.g. 8080). |
| Health check path | An HTTP path Bahriya checks to confirm the container is healthy (e.g. /healthz). The container only receives traffic once this returns a 2xx response. |
| Min CPU | The minimum CPU guaranteed to the container, in millicores (e.g. 250 = 0.25 of a core). |
| Min memory | The minimum memory guaranteed to the container, in megabytes (e.g. 256). |
| Regions | The regions where the container should run. At least one is required. |
CPU and memory
CPU is specified in millicores. 1000 millicores = 1 full CPU core. A value of 250 means the container is guaranteed a quarter of a core.
Memory is specified in megabytes. A value of 512 gives the container 512 MB.
Bahriya uses your min values as the guaranteed allocation and computes a limit (the ceiling) automatically using a configured multiplier. This means your container can burst above its minimum if spare capacity is available.
The CPU class (shared, dedicated, or premium) determines the pricing tier — see CPU Classes.
Lifecycle and status
| Status | Meaning |
|---|
provisioning | The deployment pipeline is running. |
running | The container is live and healthy across all configured regions. |
error | The pipeline failed. Check the Events tab for details. |
terminated | The container has been deleted and all resources removed. |
Updating a container
Bahriya only re-deploys when something that affects the running container has actually changed — a new image tag, adjusted resources, networking, environment variables, secrets, scaling, or regions. Cosmetic edits (renaming the container, saving the form with no changes) leave the deployment untouched and the container stays in running. When a deploy is required, Bahriya performs a rolling update with zero downtime.
Deleting a container
Deleting a container removes it from every region it was deployed to, removes its DNS records, and cleans up all associated resources. The status transitions to terminated once complete.
