Using Docker Compose locally, deploying to StackBlaze
Docker Compose is great for local development. StackBlaze runs the same pieces, but splits them by responsibility: your application containers become apps, and the databases and caches you used to run as Compose services become managed add-ons.
Doing the mapping once gets you backups, version upgrades, optional high availability, and a private network for free, instead of babysitting database containers in production. The translation is almost always mechanical; the table below covers the common cases.
Example, docker-compose.yml
version: "3.9"
services:
web:
build: .
ports: ["3000:3000"]
environment:
- DATABASE_URL=postgres://postgres:secret@postgres:5432/app
- REDIS_URL=redis://redis:6379
depends_on: [postgres, redis]
postgres:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: secret
POSTGRES_DB: app
volumes:
- pgdata:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
- redisdata:/data
volumes:
pgdata:
redisdata:
What you end up with
app web → deployed from your Dockerfile, port 3000
add-on postgres → managed PostgreSQL, attached to web
add-on redis → managed Redis-compatible cache
volume /data → persistent disk on the app
# No import command, you recreate each Compose service
# as an app or an add-on in the dashboard or a Blueprint.
Compose → StackBlaze
| Compose key | StackBlaze equivalent |
|---|---|
| build: . | App (from Dockerfile) |
| image: postgres:16 | Managed PostgreSQL add-on |
| image: redis:7-alpine | Managed Redis-compatible add-on |
| volumes: | Persistent disk |
| environment: | Environment variables / secrets |
How it maps
Under the hood
The translation follows a few consistent rules, so you always know which Compose service becomes an app and which becomes a managed add-on:
- build / image: services built from source (
build) or shipped as your own image become apps, keeping the same port and start command. - known datastores: services using a stock image such as
postgres,redis,mysql, ormongobecome managed add-ons, run and maintained for you rather than as raw containers. - volumes: named volumes on an app service become persistent disks mounted at the same path. Add-on storage is managed for you, so datastore volumes don’t carry over.
- environment: plain values become environment variables; the ones you mark sensitive become secrets. Add-on connection strings are injected for you, so you can drop the hard-coded
DATABASE_URLfrom your Compose file. - networking: Compose’s default network becomes your project’s private network. Each service is still reachable by its name, so inter-service URLs mostly carry over unchanged.
Step by step
Keep your docker-compose.yml as the reference
Your Compose file already lists everything your app needs. On StackBlaze you translate it into one app plus a few managed add-ons, rather than running every container yourself. Keep the file open, it is your checklist.
App services become StackBlaze apps
Any service you build from source (build:) or ship as your own image becomes a StackBlaze app, deployed from the same Dockerfile or image, with the same port and command. This is the part of the stack that is actually your code.
Datastore services become managed add-ons
Don't run your own postgres or redis container. Swap each datastore service for a managed add-on you attach to the app, you get backups, version upgrades, and optional high availability instead of an unmanaged container.
Wire them together
Attach the add-ons and their connection strings are injected into the app as environment variables. Other apps are reachable by their service name on the private network, so depends_on and the Compose network are handled for you.