No. The compose file and .env are generated by plain JavaScript in your browser. Domains, passwords, ports and volume names never leave your machine — a compose file with its .env is a complete map of your server.
Free Server Tool — 100% In-Browser
Docker Compose Stack Builder
Generate a production-ready docker-compose.yml for WordPress, Nextcloud, n8n, Laravel or Gitea — with your choice of database, cache and reverse proxy, healthchecks, named volumes, private networks and a matching .env file. Plus a security overlay, volume backup commands and the kompose path to Kubernetes. Built entirely in your browser.
A Stack Is Not Five Containers — It Is Twenty Decisions
Floating tags that break on the next pull, a database with no volume, ports open to the whole internet, containers restarting in a loop because the app boots before the database — every compose file encodes these decisions. This builder makes them once, correctly: pinned image tags, healthcheck-gated start order, named volumes, private networks, secrets in .env and a reverse proxy option with automatic TLS.
Every line is produced by JavaScript in your browser. Your domain, passwords and port plan are never uploaded — a compose file plus .env is a complete map of your server, and it stays on your machine.
How It Works
1. Pick the App
WordPress, Nextcloud, n8n, Laravel or Gitea — each with the correct image, volumes and wiring.
2. Pick the Services
Database (MariaDB or PostgreSQL), cache (Redis), reverse proxy with automatic HTTPS — or none.
3. Generate
A complete docker-compose.yml plus .env: healthchecks, start order, named volumes, private networks.
4. Deploy & Harden
Copy both files, docker compose up -d, apply the security overlay, and use the Ops tab to back up volumes.
Docker Compose Stack Builder
Project basics
Credentials (stay in .env)
Stack options
Generates a hardened services block to merge into your compose file: non-root users where the image supports it, read_only root filesystems with explicit tmpfs, dropped capabilities, no-new-privileges, resource limits and logging caps.
Update, backup and restore commands for the generated stack. Volume backups use a one-off helper container so the data never depends on a live app container. For off-server backups see the Backup & Restore Script Builder.
The honest path from Compose to Kubernetes is kompose — not hand-embedded manifests. Generates the conversion commands, the post-conversion checklist and the rollout verification, plus what kompose cannot translate (and what to do about it).
Everything above runs in JavaScript in your browser. Domains, passwords, ports and volume names you enter are never uploaded — a compose file with its .env is a complete map of your server, and it stays on your machine.
Stack Defaults, Explained
| Decision | Default in the output | Why |
|---|---|---|
| Image tags | Pinned (e.g. wordpress:6, mariadb:11) | A floating latest tag is a surprise deploy waiting to happen — pin the major version. |
| Start order | depends_on with condition: service_healthy | The app waits for the database to actually answer, not just to have a container ID. |
| Restart policy | unless-stopped | Survives crashes and reboots, but a manual stop stays stopped. |
| Secrets | .env file, marked in output | Passwords never belong inside the YAML that you paste into tickets and chats. |
| Persistence | Named volumes | Bind mounts to host paths break on other machines and leak permissions; named volumes are managed and portable. |
| Networks | frontend + backend, DB never in frontend | The database should be unreachable from outside the compose project. |
| Ports | DB not published at all | Databases never need a host port when the app talks over the internal network. |
| Proxy / TLS | Optional nginx-proxy or Traefik | Both companions issue Let Us Encrypt certificates automatically on first request. |
| Updates | Optional Watchtower | Automatic pulls are convenient but a risk — the Ops tab shows the safer manual update path. |
Docker Compose Stack Builder — FAQ
Are my passwords or domains uploaded anywhere?
Why MariaDB for WordPress and PostgreSQL for n8n?
WordPress, Gitea and Laravel speak both, but MariaDB remains the best-tested path for WordPress (the official image is built around MySQL semantics). n8n and Nextcloud work best on PostgreSQL — their schemas use features where Postgres is the more reliable engine. The builder lets you swap, but the defaults follow what each project documents.
What does the Security Overlay change?
It adds defense in depth: read_only root filesystems with explicit tmpfs mounts for write paths, all Linux capabilities dropped, no-new-privileges so a container process can never gain more rights, memory and CPU limits so one runaway container cannot starve the host, and a logging cap so a chatty container cannot fill the disk. Each option is a checkbox, so you apply only what your images tolerate.
How do I back up the volumes?
The Ops tab generates the exact commands: a one-off helper container runs tar against each named volume while the stack is up, database volumes additionally get a proper dump first (a live-copied database file is corrupt). For off-server copies with retention and restore runbooks, use the Backup & Restore Script Builder — restic or Borg over the directory the Ops commands produce.
Why kompose instead of embedded Kubernetes manifests?
Kubernetes manifests change with every object version, and a compose file already contains everything kompose needs. Converting with kompose gives you current, valid Deployment and Service objects for your exact stack — while a static manifest embedded in a web page would age into silence. The K8s tab lists what kompose does not translate (healthchecks become probes only partially, volumes become hostPath by default) and what to do instead.
nginx-proxy or Traefik — which one?
nginx-proxy with acme-companion is the simplest: label your app container, certificates are issued and renewed automatically. Traefik v3 is the modern default: labels do more (middlewares, redirects, TLS options), the dashboard is useful, and it speaks to Docker natively. If you already run one of them on the host, pick the same one — two proxies fighting over ports 80 and 443 is a classic self-inflicted outage.
What does Watchtower do, and is it safe?
Watchtower polls for newer image tags and re-creates containers automatically. It is convenient, but automatic also means untested: an upstream breaking change goes live at 3 AM without you. If you enable it, keep the major-version pins this builder emits — a pinned wordpress:6 tag only receives 6.x updates, so Watchtower applies patches, not surprises.
The compose file mentions UFW — do container ports bypass it?
Yes, and this surprises everyone: Docker publishes ports by writing iptables rules directly, so a published port is open even when UFW or firewalld says otherwise. That is why this builder never publishes the database port at all, keeps the app port optional (the proxy owns 80 and 443), and recommends the UFW-Docker ruleset from the Linux Command Builder if you publish ports directly.