The Bahriya Blog
Product, engineering, opinion.
Launch notes, engineering essays and the occasional sharp opinion from the team building Bahriya.
Announcements
The Vault and Configs are here — and they're the runway for what comes next
Two new subsystems land on the platform today, and together they change the shape of what you can build on Bahriya. The Vault is the new home for every piece of sensitive material a container needs to do its job. Configs is the matching home for every piece of non-sensitive material — the config files your app reads at boot.
Announcements
The Bahriya Terraform provider is now on the HashiCorp Registry
If you manage infrastructure with Terraform, you can now manage Bahriya the same way. The official Bahriya provider is live on the HashiCorp Terraform Registry and ready to use.
Announcements
Multiple custom hostnames and init jobs — HTTP containers grow up
Two features today, both aimed at the moments where a deployment stops being a single image and starts being a small system. Multiple custom hostnames on a container, and init jobs that run to completion before your main container starts.
Announcements
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.
Developer Series
Tuning a proxy cache for hit rate, latency, and origin load
Turning on proxy caching is a one-click decision. Tuning it well is where the leverage actually shows up. A 60% hit rate cuts your origin load by more than half. An 85% hit rate cuts it by almost seven times. The difference between those two numbers is almost never about the cache itself — it's about how you sized it, what you keyed it on, and where you placed it relative to your other ingress policies.
Announcements
Managed proxy caching is now live on Bahriya
Most HTTP traffic is repetitive. The same product page, the same catalogue listing, the same public API response — fetched thousands of times, served from your container thousands of times. Each one costs CPU. Each one adds a few milliseconds of tail latency. Each scraper that finds your endpoint costs you compute budget you wanted to spend on real users.
Announcements
Built-in Prometheus metrics are now live on Bahriya
Every application has its own definition of "healthy." HTTP 200s and process-alive checks tell you whether your container is running. They don't tell you whether your connection pool is saturated, your cache hit rate has cratered, or your request queue is backing up. For that, you need application-level metrics — and for most of the industry, that means Prometheus.
Announcements
Workers and cron jobs are live on Bahriya
When we launched Bahriya, the platform shipped with one container type: long-running HTTP services. That covers a large class of workloads — APIs, web applications, internal services — but it is not the whole picture. Real applications also need background processors that drain a queue and scheduled jobs that run a task on a clock.
Developer Series
Securing your container: basic auth and IP rules
When you publish a container to the public internet, you usually want some control over who can reach it. A staging deployment shouldn't be open to crawlers and script kiddies. An internal admin panel shouldn't accept traffic from random IPs. A production API shouldn't be one zero-day away from total compromise just because the application library got patched late.
Announcements
Bahriya is live — and we're opening early access
Bahriya is now live and accepting early access users.
Developer Series
Deploying a multi-pool Memcached setup on Bahriya
Memcached is one of those tools that does one thing and does it well — it caches objects in memory so your application does not hit the database on every request. On Bahriya, Memcached is a managed service that runs alongside your containers with project-private networking, so your cache is only accessible to the containers that need it.
Developer Series
The edge container cloud — and why it matters
For years, the standard way to serve a global audience was simple: deploy your application to a single region and put a CDN in front of it. Static assets — images, scripts, fonts — got cached at edge nodes around the world. Dynamic requests travelled back to the origin, wherever that was.
Announcements
The path to building Bahriya
Bahriya did not start as a cloud platform. It started as a frustration.
Developer Series
Deploying to 4 regions: Amazon ECS vs Bahriya
You have a containerised application. You want to deploy it to four regions — Europe, US East, US West, and Asia — with autoscaling, TLS, health checks, and DNS routing. This is one of the most common deployment scenarios for any application that serves a global audience.
Developer Series
CDN-level speed with Memcached and GeoDNS
CDNs solve a simple problem: put content close to users. A request from Tokyo should not travel to Frankfurt to fetch a product image or a JSON payload that has not changed in hours. CDNs cache content at edge locations and serve it locally.