For Docker

Containers on
the open edge

Spin up a VM, run any Docker image. Compose your stack, front it with a global CDN, store state in S3-compatible Edge Storage. No proprietary runtime, no vendor lock-in.

Start your trial Read the bootstrap docs

# bootstrap-docker.sh

curl -fsSL https://get.docker.com | sh

git clone git@github.com:me/app .

docker compose up -d

# Provision the VM with that script

$ edge compute create \

--image ubuntu-24-04 --plan medium \

--script ./bootstrap-docker.sh

# Front the stack with the CDN

$ edge cdn create app.example.com \

--origin https://<vm-ip>

✓ Containers running, CDN warm

Why ship containers on Edge

Real VMs you control, sized to fit, with a global network already wired in. The deployment story you sketched on a whiteboard, working.

Plain Docker, plain Linux

Provision a VM, install Docker, run your containers. No proprietary container runtime, no funny image registries, no surprises.

Compose-ready

docker compose up works exactly as you'd expect. Multi-container apps with shared networks and named volumes — straight from your repo.

Persistent state, off-box

Mount NVMe volumes for stateful containers, or push uploads and backups to S3-compatible Edge Storage. Your containers stay disposable.

Global delivery

Deploy near any user with a single CLI flag, then front it all with the Edge CDN. Zero egress on bandwidth out to your users.

Bootstrap from one script

Use the Edge CLI's --script flag to install Docker, pull images and start your stack on first boot. Idempotent, repeatable, version-controlled.

Agent-deployable

"Deploy this Compose file to api.example.com" — the Edge agentic API can stand up the VM, configure DNS and front it with a CDN deployment.

Reference architecture

How a containerised app maps to Edge

Containers on a VM, persistent state in object storage, traffic through the global CDN. Same primitives as a hyperscaler — without the abstraction tax.

Compute

Hosts the Docker daemon and your running containers

Storage

S3-compatible object store for image artefacts, uploads, backups

CDN

Caches static assets your containers serve, with zero egress

DNS

Anycast DNS for routing and per-environment subdomains

# compose.yml

services:

app:

image: ghcr.io/me/app:latest

restart: unless-stopped

env_file: .env

ports: ["80:3000"]

db:

image: postgres:16

volumes: ["pgdata:/var/lib/postgresql/data"]

caddy:

image: caddy:2

volumes:

pgdata:

Common questions

Can I use Docker Compose?

Yes. Compose runs unchanged on an Edge VM. We recommend committing your compose file and a small bootstrap script that installs Docker and runs `docker compose up -d` on first boot.

What about Kubernetes?

You can run k3s or k8s yourself on a cluster of Edge VMs. For most workloads under, say, 20 containers we strongly recommend Compose on a single VM (or a couple) — it's dramatically simpler.

Where do my container images live?

Anywhere you like — Docker Hub, GHCR, GitLab registry, or self-hosted. Edge Storage works as an OCI-compatible artefact store if you want to keep registries in-network.

How do I update a running container?

Standard Docker workflow: pull the new image, recreate the container. Wrap it in a CI step or a `watchtower`-style updater. The VM is yours, do it however you like.

By Stack