Guide
Docker Compose for a small business: running your apps on one server, cleanly
Docker Compose lets you describe an application and everything it needs (the app itself, its database, a background worker) in one YAML file, then start it all with one command, docker compose up. For a small business it is a simple, portable way to run several apps on one server you control, provided a few production settings are right: restart policies, health checks, secrets kept out of the code, and updates that replace one service at a time.
What Compose is, in plain words
Docker's documentation describes Compose as a way to use a YAML configuration file, the Compose file, to configure your application's services, and then create and start all of them from that configuration with the Compose command line. The preferred file name is compose.yaml (older names such as docker-compose.yml still work).
The file describes a few kinds of building blocks:
| Building block | What it is (Docker's definitions, simplified) | Example |
|---|---|---|
| Service | The same container image and configuration, run one or more times | Your web app, its database, a worker |
| Network | Lets services talk to each other | The app reaching its database by name |
| Volume | Persistent storage that survives restarts | Database files, uploaded documents |
| Config | Configuration that depends on the platform or runtime | An application settings file |
| Secret | Sensitive configuration that should not be exposed | Database password, API keys |
Why it suits small businesses
It is not the answer to everything. If you need automatic scaling across many machines or a managed database with guarantees you cannot provide yourself, a managed platform may suit better. For many small business apps, one well-run server is enough.
- One file per app documents what runs and how: a new developer, or your next provider, can read it.
- Portable: the same file runs on a laptop and on a server, which makes moving host far less risky.
- Several apps on one server: each app in its own folder with its own Compose file, sharing a reverse proxy in front.
- No platform lock-in: you can rent any Linux server and keep the server, the data and the bill in your name.
The settings that matter in production
- Restart policy: by default, Docker does not restart a container (policy no). Docker also offers always, on-failure and unless-stopped; its production guide suggests a policy such as restart: always to avoid downtime.
- Health checks: a healthcheck defines a test command run at an interval, with a timeout, a number of retries and a start_period. With depends_on and condition: service_healthy, a service waits until another reports healthy before starting.
- Secrets and environment: env_file passes environment variables from files; values in the environment section take precedence. secrets are mounted read-only under /run/secrets/ in the containers that need them. Neither belongs in your code repository.
- No code mounted from outside: Docker's production guide recommends removing volume bindings for application code, so the code stays inside the container and cannot be changed from outside.
- A production override file: keep production-only changes in a separate file such as compose.production.yaml and apply it with docker compose -f compose.yaml -f compose.production.yaml up -d.
Updating an app without touching the others
Docker's production guide shows how to redeploy one service after a code change: rebuild its image, then run docker compose up --no-deps -d web, which stops, removes and recreates only the web service; --no-deps prevents Compose from also recreating the services it depends on. In practice we go one step further: images are built elsewhere, on a CI service, and the server only pulls and restarts the new image.
A safe routine for a small server
- One folder per app, with its Compose file, an example environment file, and a short README.
- Secrets in environment files or Compose secrets on the server only, never in Git.
- Health checks on every service that serves traffic, and a status page that reads them.
- Images built on a CI service; the server pulls them.
- Daily snapshots of the server and regular database dumps, with a restore tested.
- Updates one service at a time, with the previous image kept for a quick rollback.
How we use it at Takat
Docker Compose is how we run our own platform. We moved apps off Cloud Run and Vercel onto Docker Compose and consolidated more than 100 hosted projects onto our own server. Builds run on GitHub Actions, never on the production server; services have health checks; the server takes daily snapshots; and failed releases roll back automatically. Every project has dev, UAT and prod environments (see our guide). See Hosting & DevOps and Cloud migration.
Questions we get
Is Docker Compose suitable for production?
Docker publishes a guide to using Compose in production, with recommended changes: a restart policy, different environment settings, no code mounted from outside the container, and a separate production file. Many small business apps run well this way on one server.
What is the default restart policy?
no: Docker does not restart the container under any circumstances unless you set another policy, such as always, on-failure or unless-stopped.
Where should passwords and API keys go?
Out of your code repository: in environment files kept on the server, or in Compose secrets, which are mounted read-only under /run/secrets/ in the containers that need them.
Can several apps share one server?
Yes. Each app gets its own folder and Compose file, and a reverse proxy in front routes each domain to the right app. The server must have enough memory and disk for all of them, which monitoring should watch.
Sources
- Docker Docs: How Compose works (application model) (checked 2026-10-06)
- Docker Docs: Compose file reference, services (checked 2026-10-06)
- Docker Docs: Use Compose in production (checked 2026-10-06)