DCM - Docker Compose Maker

Live Demo 🚀 • Install 💻 • Contribute 🤝 • Supported Tools 📦 • Screenshots 📸

📋 About

Note

🌟 Community-Driven Project: DCM started as a simple tool but aims to become the go-to resource for Docker Compose configurations, powered by the community. We believe everyone has their favorite self-hosted tools, and we'd love for you to share yours! Whether you're using a popular application or a hidden gem, your contribution helps others discover and easily deploy great software.

DCM (Docker Compose Maker) turns a handful of clicks into a ready-to-use docker-compose.yaml and .env for your self-hosted apps. The catalog merges DCM's own compose definitions with the app catalog of self-host, so you also see apps DCM has no YAML for yet, marked self-host only.

Every selection shows the matching self-host install <apps> command. self-host is the sister project: one Go binary that installs and wires these apps for you, for people and for AI agents. Rather not manage YAML? Use it. Prefer to own the YAML? DCM stays fully usable on its own.

Tip

Most containers come pre-configured with best practices and sensible defaults, saving you hours of documentation reading and configuration tweaking.

💡 Share Your Stack: Using a great tool that's not listed here? We'd love to include it! Check out our contribution guide to help others discover and use your favorite containers.

🔧 How to Use DCM

Using Docker Compose Maker is simple and intuitive:

1. Select containers - Browse the curated list of self-hosted applications and click to select the ones you want to include
2. Use templates - Choose from predefined templates in the Template Gallery for common stacks like media servers
3. Configure settings - Adjust environment variables, paths, and other common settings
4. Generate your configuration - Click "Copy Compose" to view and customize your docker-compose.yaml
5. Deploy your stack - Use one of the following methods to deploy your containers:

Important

All containers are configured to use environment variables like ${PUID}, ${PGID}, and ${TZ}. Make sure to set these in your deployment to avoid permission issues.

Deployment Options

Once you have your docker-compose configuration, you have several ways to deploy it:

Copy & Paste

Simply copy the generated docker-compose.yaml and .env content, save them locally, and run docker-compose up -d to start your containers.

Download Files

Download the generated docker-compose.yaml and .env files directly from the interface, then use them with your preferred Docker management tool.

Note

The downloaded .env file contains all the environment variables referenced in your docker-compose.yaml. Keep both files in the same directory when deploying.

Portainer Stacks

If you're already using Portainer to manage your Docker environment, you can easily deploy your configuration as a stack:

1. Navigate to your Portainer dashboard and select Stacks from the sidebar
2. Click Add stack
3. Give your stack a name
4. Select Web editor and paste the generated docker-compose content
5. (Optional) Add the environment variables from the .env file
6. Click Deploy the stack

Caution

When using Portainer Stacks, you'll need to manually add the environment variables or upload the .env file, as Portainer doesn't automatically read the .env file in all configurations.

Using Portainer provides a user-friendly web interface to manage, update, and monitor your containers without needing command-line tools.

Other Docker Management Tools

The generated compose file works with any tool that supports docker-compose syntax, such as Docker Desktop, Rancher, Yacht, or command-line tools.

🚀 Quick Start

If you want to try DCM for yourself, there are several ways to get started:

🌐 Use the Online Version

Visit compose.ajnart.dev to use the tool immediately without installation.

Note

The online version includes analytics for usage tracking, while the self-hosted version does not.

🐳 Run with Docker

Run with a single command:

docker run -p 7576:7576 --name dcm --rm ghcr.io/ajnart/dcm

Then visit http://localhost:7576 in your browser.

The Docker image is available for multiple platforms:

• linux/amd64
• linux/arm64
• linux/arm/v7

📦 Using Docker Compose

Create a docker-compose.yaml file:

services:
  dcm:
    image: ghcr.io/ajnart/dcm
    container_name: dcm
    ports:
      - "7576:7576"
    restart: unless-stopped

Then run:

docker-compose up -d

🚀 Using Easypanel

Easypanel is a self-hosted Docker deployment platform. It has a one-click Easypanel template for DCM, which runs the image above.

🛠️ Build from Source

1. Clone the repository:

git clone https://github.com/ajnart/dcm.git
cd dcm

2. Install dependencies:

First install Bun if you haven't already, then run:

bun install --linker hoisted

Note

The hoisted linker is required: the default isolated linker breaks Turbopack.

Warning

Using npm instead of Bun may result in longer installation times and potential compatibility issues. We strongly recommend using Bun for development.

3. Build and start:

bun run build
bun start

Community upvotes on Cloudflare Pages

The gallery supports anonymous community upvotes through Pages Functions and Workers KV. No accounts, traditional database, or Next.js server are required. Docker, bun start, bun dev, and other static hosts remain fully usable without an API: upvote buttons show an unavailable state rather than inventing counts. Nothing contacts the public DCM instance.

Voting is opt-in. The default wrangler.toml has no KV binding and voting stays disabled until both bindings below exist:

1. Create a Workers KV namespace for votes in your Cloudflare account. Add its binding to wrangler.toml, replacing the namespace ID with your own. Use a separate namespace for preview deployments so previews cannot change production votes:

[[kv_namespaces]]
binding = "UPVOTES"
id = "YOUR_PRODUCTION_NAMESPACE_ID"

[[env.preview.kv_namespaces]]
binding = "UPVOTES"
id = "YOUR_PREVIEW_NAMESPACE_ID"

2. In the Pages project's Settings → Variables and Secrets, add an encrypted runtime secret named VOTE_IP_SECRET, independently for production and preview. Generate a random value of at least 32 bytes and keep it stable. Never use a NEXT_PUBLIC_ variable or commit the secret. Wrangler configuration is the source of truth for KV bindings; do not rely on a dashboard-only KV binding when deploying with this file.
3. Build and deploy from the repository root with bun run deploy. Wrangler includes functions/ alongside out/; uploading only out/ to a static host does not deploy the API. public/_routes.json limits Function invocation to /api/*, leaving the gallery and other assets static.

For local-only development, put VOTE_IP_SECRET="local-development-only" in .dev.vars (gitignored), build the static export, and run:

bun run build
bunx wrangler pages dev out --kv=UPVOTES

Wrangler uses local KV storage by default; this does not create or deploy cloud resources. Test the API and gallery through Wrangler's URL, not next dev. API calls without Cloudflare's CF-Connecting-IP header cannot vote. For manual local requests, provide a test IP in that header and an Origin matching the local URL.

API and storage

• GET /api/stats returns { "counts": { "jellyfin": 0, ... } } for the current merged catalog, including self-host-only entries. One gallery request loads all counts. Responses are cached for 60 seconds in the browser and per Cloudflare edge location; query strings do not bypass the edge cache.
• POST /api/vote accepts { "containerId": "jellyfin" } as JSON, with a same-origin Origin header and a body of at most 1 KiB. IDs must exist in the same catalog used by the gallery. It returns { "accepted": true }, or { "accepted": false } if that network has already voted for the container. Votes cannot be removed.
• Each vote writes vote:{containerId}:{HMAC}. HMAC-SHA-256 uses the server secret, container ID, and Cloudflare-provided IP. Raw IPs are not stored, sent back, or logged by voting code. A separate rate:{HMAC} key expires after 60 seconds and limits new votes across containers from the same IP; rejected votes return 429 with Retry-After. Changing forwarded-IP headers does not select the voting identity.
• Browser storage remembers successful votes only as a UX hint; clearing it does not bypass server deduplication. Failed writes do not show a successful vote. Missing bindings, unavailable KV, or exhausted quotas return 503, without breaking compose generation.

Limitations and costs

KV has no atomic increments or transactions. Counting durable, deterministic ballot keys avoids losing distinct votes during concurrent counter updates, and repeated writes for the same IP/container still count once. However, KV reads and listings are eventually consistent: counts can lag by 60 seconds or more, plus the response cache. The UI increments after acknowledgement, so a refreshed page can temporarily show an older count. Parallel reads can miss a recent ballot or throttle marker; the throttle is best-effort, not a strict abuse-prevention boundary. A failed ballot write after the throttle write can require waiting 60 seconds before retrying.

This is a community signal, not verified ratings or a guarantee that a container works. Shared public IPs share a vote; changing IP/VPN can evade deduplication. Rotating VOTE_IP_SECRET permits new votes from previously seen networks, while existing votes remain counted. Ballots do not expire and contain pseudonymous identifiers; restrict namespace access and consider your privacy/retention obligations.

An accepted vote normally uses two KV reads and two writes. A cold stats response lists every ballot in pages of 1,000, with no per-ballot reads; costs grow with total votes and active edge locations. The API fails unavailable rather than returning partial counts if listing exceeds 50 pages (about 50,000 ballots). Monitor KV list, read, write, storage, and Pages Functions quotas: free-tier operation is not guaranteed, and listing quotas can be reached before read quotas. For higher traffic or strict throttling/count consistency, move aggregation and coordination to a Durable Object rather than adding non-atomic counters.

Cloudflare references: Pages bindings and secrets, Wrangler Pages configuration, KV listing and pagination, and KV consistency.

🧰 Supported Tools

DCM includes configuration for many popular self-hosted applications, including:

📺 Media Management:

• Media Servers: Jellyfin, Plex, Emby
• Media Automation: Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Bazarr, Whisparr
• Media Requests: Jellyseerr, Overseerr, Doplarr, Requestrr

🔍 Dashboards & Management:

• Dashboards: Homarr, Heimdall
• Container Management: Portainer
• Media Analytics: Tautulli

📥 Download Management:

• Torrent: qBittorrent
• Usenet: NZBGet, NZBHydra 2
• Indexers: Jackett, Prowlarr

🗄️ Databases:

• SQL: MariaDB, MySQL, PostgreSQL
• NoSQL: MongoDB, Redis

📊 Monitoring & Automation:

• Monitoring: Grafana, Prometheus
• Updates: Watchtower
• Home Automation: Home Assistant

🔐 Security: Vaultwarden

💾 Storage & Files: Nextcloud

Each tool includes a detailed description, GitHub star count, and pre-configured docker-compose settings.

🎁 Want it installed for you?

Note

self-host is in preview: public downloads are not available yet, so the install command only works with access to its repository. The in-browser playground works for everyone.

Skip the YAML. self-host is one Go binary that installs, wires (API keys, Homarr tiles, download clients) and repairs self-hosted apps with Docker Compose. It has a terminal dashboard for people and --json commands for AI agents. DCM links to it from the header, the selection bar and the Copy Compose modal, prefilled with your selected services (https://self-host.fyi/?apps=<ids>&ref=dcm).

The self-host catalog is vendored in lib/selfhost-catalog.json. Refresh it with bun run sync:selfhost.

🧪 Testing

DCM uses Bun for testing. To run the tests:

# Run all tests
bun test

# Run Docker Compose validation tests
bun test:compose

# Run container schema validation tests
bun test:containers

🔄 Template Gallery

DCM includes a Template Gallery that allows you to quickly add predefined stacks of containers based on common use cases:

• Media Server Stacks: Complete media server setups with Jellyfin/Plex and related tools
• Development Environments: Web development stacks with databases and web servers
• Monitoring Solutions: Grafana, Prometheus, and other monitoring tools
• Database Clusters: Various database engines with management tools
• Security Tools: Password managers and security-related containers
• And more!: Smart home hubs, personal cloud solutions, and other useful templates

To use the Template Gallery:

1. Click the "Template Gallery" button at the top of the main page
2. Browse or search for templates that match your needs
3. Click "Use Template" to add all containers from that template to your selection
4. Return to the main page to customize your selected containers

You can combine multiple templates to create your perfect self-hosted environment!

🖼️ Screenshots

User Interface

Generated docker compose file

🤝 Contributing

We welcome contributions to DCM! Whether you want to add new container definitions, improve documentation, or fix bugs, your help is appreciated.

Please check our CONTRIBUTING.md guide for detailed instructions on:

• How to add new container definitions
• Code style guidelines
• Testing requirements
• Pull request process

The easiest way to contribute is by adding new container definitions to our growing collection!

📜 License

This project is licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only) - see the LICENSE file for details.

💖 Support

If you find this tool useful, consider supporting the project by:

• ⭐ Starring the repository on GitHub
• 🐦 Sharing it on social media
• ☕ Buying me a coffee

📞 Contact

• GitHub: @ajnart

---

Made with ❤️ by ajnart