Stateful containers, replicated by default
Containers on Bahriya have always been great at running stateless web apps and workers. Today they get a lot better at the other half of the job: keeping state.
We're shipping ephemeral storage and persistent storage for every container type. You get a few free GB of scratch space out of the box, the ability to attach replicated SSD volumes that survive restarts, and per-minute billing on every byte beyond the freebie tier.
Ephemeral storage — free up to 3 GB, then $0.10/GB/month
Every container now ships with 3 GB of ephemeral storage included for free — the kind of scratch space you would have written to /tmp on a regular server. If your app needs more, you can scale up to 10 GB per pod in 1 GB increments. Each extra GB beyond the free tier is $0.10 per GB per month, billed per minute.
Ephemeral storage lives only for the lifetime of the pod. When a replica restarts, the contents go with it. That's the trade-off for it being fast and local — and for the rest of your storage needs, we have an answer too.
Persistent storage — replicated block SSD at $0.30/GB/month
For state that needs to survive — databases, vector stores, application state, anything you can't afford to lose on a restart — every container can now attach persistent volumes.
Bahriya stores persistent data as replicated block SSD storage. Every byte is kept in three independent copies behind the scenes, so a single disk failure can't take your data offline. The price reflects that durability: $0.30 per GB per month, billed per minute.
You can attach multiple persistent volumes to one container, each mounted at its own path inside your image. Pick the size from 1 GB up to 50 GB per volume, with a default of 3 GB the first time you enable it. Add a data volume at /data for general state, a /var/lib/postgresql mount for a database — whatever your application expects.
One thing to know about replicas
Persistent volumes are stored per replica. Each replica gets its own independent copy of every volume you've attached. If you run three replicas of a container with a 10 GB volume, you have three 10 GB volumes provisioned and billed.
This is the right thing to do for state safety — every replica gets its own consistent view — but it's worth seeing in writing because the cost preview multiplies up quickly. Two replicas with two 5 GB volumes is 20 GB billed, not 10. We show the full bill in the console before you save so there are no surprises.
For the same reason, autoscaling and persistent storage don't mix. Autoscaling can add and remove replicas at any time; doing that with persistent state would silently provision new (billed) volumes when scaling up and permanently destroy the data on removed replicas when scaling down. Neither is what anyone wants. If you want autoscaling, stay stateless. If you want persistent storage, pick a fixed replica count.
Where to find it
Both ephemeral and persistent storage live under a new Storage section in the container form, in both the console and the admin app. The cost preview updates as you change the size — set the dials, see the bill, save.
There's full coverage in the knowledgebase: ephemeral storage and persistent storage. In Reis YAML, both live under the new storage: group:
kind: container
handle: my-database
name: my-database
image: registry.example.com/team/postgres:16
regions: [helsinki-1]
workload:
cpu: "500"
memory: "1024"
scaling:
replicas: "1"
storage:
ephemeral_storage_gb: 5
persistent_volumes:
- name: data
mount_path: /var/lib/postgresql
size_gb: 20
Happy shipping.
