DCM (Docker Compose Maker): a web picker for home server compose files

The copy-paste problem DCM targets

Setting up a home server stack usually means opening six or seven project READMEs and assembling their compose snippets by hand. Each project names its environment variables differently, picks its own host port, and assumes a different volume layout. DCM's stated goal is to remove that step: the README says it helps you "create docker-compose.yaml files for your self-hosted applications" by selecting from a curated list and generating a ready-to-use file. The intended user is someone running Docker on a home machine, a NAS, or a small VPS who wants Jellyfin, Sonarr, Prowlarr and a dashboard running without reconciling documentation. The README also frames the project as community-driven, with a contribution guide for adding containers that are not yet listed. That framing matters for how you should read the catalog: it is a maintained list, not a mirror of every upstream project.

Selection, templates, generation: the actual flow

The README describes a four-step flow. You browse the curated list and click to select containers. You can instead start from a predefined template in the Template Gallery, which the README gives as an example for common stacks like media servers. You then adjust environment variables, paths and other common settings. Finally you click "Copy Compose" to view and customize the generated docker-compose.yaml. The output is two artifacts, not one: a compose file and a .env file. The README notes that the downloaded .env contains all the variables referenced in the compose file and that both must live in the same directory when you deploy. The generated services are built around three shared variables, ${PUID}, ${PGID} and ${TZ}, which the README flags as something you must set to avoid permission issues. That is the core design decision: rather than emitting literal uid and gid values per service, DCM standardizes on a single variable set, which is why the .env file is inseparable from the compose file. There is no server-side state described in the README; the tool is a web interface over a container definition list, and the deployment targets it names are plain docker-compose, Portainer stacks, Docker Desktop, Rancher, Yacht, or the command line.

Running DCM itself on port 7576

The README gives a single-command path: docker run -p 7576:7576 --name dcm --rm ghcr.io/ajnart/dcm, then open http://localhost:7576. The image is published for linux/amd64, linux/arm64 and linux/arm/v7, so a Raspberry Pi running 32-bit ARM is covered. A compose deployment is also documented, with a service named dcm using image ghcr.io/ajnart/dcm, container_name dcm, the port mapping "7576:7576", and restart: unless-stopped. Building from source requires Bun rather than npm; the README warns that npm may produce longer installs and compatibility issues, and gives bun install, bun run build, bun start as the sequence. There is one deployment detail worth reading twice. The README states that the hosted version at compose.ajnart.dev includes analytics for usage tracking while the self-hosted version does not. If you care about that distinction, running the container yourself is the way to get the version without it. Portainer users get an explicit caution: Portainer does not automatically read the .env file in all configurations, so you must paste the variables or upload the file manually.

Where the generated file stops being enough

The generator produces a starting point, and the README is honest about the seam. The Portainer note is the clearest failure mode: a compose file that depends on ${PUID}, ${PGID} and ${TZ} will start containers with empty or default values if the .env is not loaded, and the symptom is permission errors on bind mounts rather than a clean startup failure. The second limitation is catalog coverage. The supported tools list is long but finite, and the README treats additions as contributions rather than as an automated sync with upstream. A project that changes its recommended environment variables or its default port after the DCM entry was written will not necessarily be reflected, and nothing in the README describes an update mechanism that would catch that drift. Third, the templates are described only as "predefined" and "common stacks like media servers"; the README does not enumerate them, so you cannot judge coverage without opening the interface. If you already maintain hand-written compose files with pinned image tags, healthchecks and explicit networks, DCM's output will look thin next to them and you will spend the saved time re-adding what it omits.

DCM versus writing compose by hand or copying upstream examples

The obvious alternative is the upstream documentation itself. Every project DCM lists publishes its own compose example, and those examples are maintained by the people who ship the image, so they track changes in environment variables and volumes. DCM's advantage is aggregation: one interface, one variable convention across services, and a .env that already matches the compose file. The cost is an extra layer between you and upstream, updated by contributors rather than by the image authors. A second alternative is a full management UI such as Portainer, which DCM explicitly integrates with rather than replaces. Portainer deploys and manages stacks you already have; DCM only produces the stack definition. They are complementary, and the README's Portainer section is essentially an admission that the handoff between them is manual. If your goal is ongoing management, updating images and watching container health, DCM does not do that job and does not claim to.

Licence, hosting and what maintenance looks like

DCM is licensed AGPL-3.0. That is a copyleft licence with a network clause: if you modify the code and let users interact with it over a network, the AGPL's source-availability obligation is generally understood to apply to your modified version. Running the unmodified image for yourself does not trigger anything unusual, but if you fork DCM and host it for others, read the licence text rather than this summary. I am not a lawyer and this is not legal advice. On maintenance: the repository shows a single release, tagged v1 and dated 2025-10-02, with the last push to main in August 2026. That combination suggests active development on main with a thin release history, so if you deploy from ghcr.io/ajnart/dcm you are likely tracking a moving image rather than a versioned one. The README shows no tag pinning in its example compose file, which means an unattended restart could pull a changed image. If you want reproducibility, pin a digest yourself; the project does not do it for you. Upgrading DCM itself is cheap because it holds no database or persistent state in the documented setup, but the stacks you generate with it are yours to maintain from then on.

Who this fits, and what to check before you commit

DCM fits the person standing up a home server for the first time, or rebuilding one after a disk failure, who wants a media stack running tonight. It also fits anyone who wants to browse what exists in the self-hosted space before choosing, since the supported tools list doubles as a catalog of media servers, automation tools, request managers and dashboards. It does not fit teams running compose files in CI with pinned digests and review processes, because the generator emits a starting point rather than a reviewed artifact. Before you commit, generate one stack and compare it line by line against the upstream compose examples for the same images. Check three things in particular: that every service references ${PUID}, ${PGID} and ${TZ} and that your .env actually sets them, that no host port in the output collides with something already listening on your machine, and that the volume paths match where your data actually lives. If the catalog is missing a container you need, the contribution guide is the documented route in, and until that entry exists you are back to copying from upstream.

Editorial conclusion

Adopt DCM if you are assembling a first or second home server stack and want a starting compose file plus a matching .env without reading a dozen upstream READMEs. Skip it if your stacks are already version-controlled and hand-tuned, or if you need a generator that tracks upstream image changes automatically, because DCM's catalog is maintained by contributors rather than by the projects it lists. Before relying on it, generate one stack and diff the output against the upstream compose examples for the same images, paying attention to whether each service uses ${PUID}, ${PGID} and ${TZ} and whether any ports or volume paths collide with what you already run.

Official sources

1. ajnart/dcm on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases