The edge container cloud — and why it matters

meezaan

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.

This worked well enough when most of the web was static content with a thin dynamic layer. But modern applications are different. APIs return computed results. Pages are personalised. Search results, product listings, and dashboards are generated on every request. The CDN can cache the shell, but the substance of the response still has to come from the origin.

The round-trip to a single origin creates the latency your users feel. A user in Singapore hitting an API in Frankfurt adds 150-250ms of network latency before your application even starts processing the request. Multiply that across every API call on a page, and you have a slow experience that no amount of frontend optimisation can fix.

Edge functions: a half-step forward

Edge function platforms — Cloudflare Workers, Vercel Edge Functions, Deno Deploy — addressed part of this problem. They let you run code at edge locations, close to users, with low latency.

But they came with significant constraints:

Language lock-in — most only support JavaScript or TypeScript, sometimes with WebAssembly as a workaround
Execution time limits — typically 10-30 seconds, ruling out any non-trivial computation
No persistent connections — no WebSockets, no gRPC streams, no connection pools
No system dependencies — no custom binaries, no native libraries, no GPU access
Stateless by design — every request starts from scratch; any state requires an external service call, which often hits... a centralised origin
Vendor-specific APIs — your code is written against a proprietary runtime, not standard APIs

Edge functions are excellent for request transformation, authentication checks, and A/B test routing. But they are not a deployment target for real applications. You cannot run a Django API, a Spring Boot service, a Go gRPC server, or a PHP application on an edge function platform.

The result is an awkward split: your edge layer handles lightweight logic, but your actual application still runs in one region. You have not eliminated the latency problem — you have just moved part of it.

The edge container cloud model

An edge container cloud takes a different approach. Instead of constraining what can run at the edge, it removes the constraints entirely. You deploy standard containers — the same images you already build — to multiple regions. Each region runs your full application independently. GeoDNS routes users to the nearest region automatically.

This is what Bahriya does.

There is no special runtime to target. No SDK to integrate. No language to learn. If your application runs in a container, it runs on Bahriya — in every region you choose.

How it works

You build a standard OCI container image — using Docker, Podman, Buildpacks, or anything else
You select your regions — Falkenstein, Helsinki, Virginia, Singapore, and more
Bahriya deploys your container to every selected region — with autoscaling, TLS, health checks, and DNS configured automatically
GeoDNS routes each user to the nearest region — a user in Tokyo hits Singapore, a user in London hits Falkenstein, a user in New York hits Virginia
Each region runs independently — its own instances, its own autoscaling, its own health checks

The entire setup is a single YAML file:

kind: container
project: my-app
handle: api
name: API
image: ghcr.io/myorg/api:v2.1.0
regions:
  - falkenstein-1
  - helsinki-1
  - virginia-1
  - singapore-1
workload:
  cpu: "500"
  memory: "512"
  port: "8080"
  healthcheck: /healthz
scaling:
  replicas: "2"
  max_replicas: "10"
  autoscalingtargetcpu: "70"
networking:
  customdnsmode: geo

reis apply -f production.yml

Your application — whatever language, whatever framework, whatever dependencies — is now running at four edge locations with geographic routing. No CDN layer. No function wrapper. No origin to fall back to. Every region is the origin.

What this changes for your architecture

When your full application runs in every region, several architectural problems disappear:

Latency becomes consistent

Every user hits a nearby instance. There is no "origin penalty" for users far from your primary region. A user in Helsinki and a user in Virginia both get the same low-latency experience, because both are hitting a local instance of the same application.

CDN invalidation disappears

You do not need a CDN for dynamic content when the application itself is at the edge. There is nothing to cache and nothing to invalidate. The response is generated locally, from the local instance, with access to local caching (Memcached on Bahriya runs in the same regions as your containers).

You stop splitting your logic

With edge functions, you inevitably split your application into "edge logic" and "origin logic." This creates two deployment targets, two testing surfaces, and two sets of constraints to reason about. With edge containers, your entire application is one artifact deployed everywhere. One build, one test suite, one deployment.

Multi-region becomes a feature, not a project

Adding a region is not a multi-week infrastructure project. It is one line in your YAML file:

  regions:
    - falkenstein-1
    - helsinki-1
    - virginia-1
    - singapore-1
    - ashburn-1      # added

Remove a region the same way. Scale each region independently. The infrastructure follows your configuration, not the other way around.

When you still need a CDN

Edge containers do not replace CDNs for static asset delivery. If you serve large images, video, or downloadable files, a CDN with points of presence in 200+ locations is still the right tool. CDNs are purpose-built for caching immutable content at massive scale.

What edge containers replace is the pattern of using a CDN as a proxy for dynamic content — the pattern where your CDN is not really caching anything, just adding a hop between the user and your application.

The comparison

	Single region + CDN	Edge functions	Edge containers (Bahriya)
Languages	Any	JS/TS only	Any
Execution model	Long-running process	Request handler (10-30s)	Long-running process
Persistent connections	Yes	No	Yes
System dependencies	Yes	No	Yes
Dynamic content latency	High (origin round-trip)	Low (but limited logic)	Low (full application)
Cache invalidation	Complex	N/A (no caching)	N/A (no caching)
Vendor lock-in	Moderate (cloud provider)	High (proprietary runtime)	None (standard OCI images)
Add a region	Weeks of infrastructure	Automatic (vendor-managed)	One line of config

Summary

The edge container cloud is not a new abstraction on top of existing infrastructure. It is a different model: your real application, running in full, at every edge location you need — without language restrictions, execution limits, or vendor lock-in.

Bahriya is built around this model. You bring standard containers. You pick your regions. You deploy. GeoDNS handles routing. Autoscaling handles load. TLS, DNS, and health checks are automatic. Your application runs close to every user, everywhere.

That is what edge computing should have been from the start.