awesome-compose: thirty-nine local stacks, a Wasm icon, a no-production rule

The repository's own note says these samples must not be deployed in production

The disclaimer sits above the list, not inside it. The samples are intended for local development environments such as project setups and tinkering with software stacks, and they must not be deployed in production environments. That is the project's position, stated in the file a reader sees first.

The consequence is easy to lose once you are inside a directory. A sample such as Nextcloud with PostgreSQL or Gitea with PostgreSQL is a real, self-hosted application, and a reader who copies the compose file, changes the passwords and points a hostname at it has crossed the line the note draws. Nothing in the sample directory stops that, because the note lives one level up in the README. The only warning attached to a specific group is in a section heading, where it applies to the platform tier alone.

So the practical reading rule is simple and worth stating before you copy anything: treat every directory in this repository as a local development fixture, and re-derive the operational parts yourself, which means storage, backups, secrets, TLS and upgrades.

Three tiers, and only one of them carries a not-production-ready heading

The list is organised into three groups, and the difference between them is not difficulty but intent. The first group is applications with multiple integrated services, twenty one entries from ASP.NET with MS SQL through Go behind NGINX with MySQL, React with a Rust backend on Postgres, and two WasmEdge samples. The second is single service samples: Angular, Spark, VueJS, Flask, PHP, Traefik, Django, FastAPI, plus a Minecraft server, Plex, Portainer and Wireguard. The third is basic setups for different platforms, headed not production ready and useful for personal use, with Gitea, Nextcloud in two configurations, Pi-hole with cloudflared over DoH, Prometheus with Grafana and Wordpress with MySQL.

The first two groups carry no warning of their own. A reader scanning for a name, seeing a Nextcloud entry in the third group and an Elasticsearch, Logstash and Kibana entry in the first, gets one explicit signal and one silent one, and the global note applies equally to both. That is a documentation design choice rather than a defect, but it means the third heading cannot be read as a description of the other two.

Every sample is the same two commands and a compose.yaml at the directory root

The running instructions are deliberately thin, which is what makes the list usable as a starting point. The root directory of each sample contains the `compose.yaml` that describes its service components, and you go into that directory and run:

docker compose up -d

To stop and remove all containers of the sample application, run:

docker compose down

The two commands are identical across every sample, so the entire difference between a Go application behind NGINX and a React application with an Express backend lives in files you have to read. Each sample also has its own README.md, and that file is where the structure and the expected output are described, which means the repository README hands you the entry point and the sample README hands you the meaning.

One consequence follows from `down` removing containers: a sample directory is disposable. There is no documented way to upgrade a running sample, move it between machines or keep its state, because the model on offer is throw it away and run it again. Prerequisites are Docker and Docker Compose, with Docker Desktop on Windows and macOS and a separate Docker install plus Docker Compose on Linux.

Docker+Wasm compatibility is signalled by an icon, not by a sentence

One compatibility claim runs through the list, and it is carried visually. A line above the first group says that an icon indicates the sample is compatible with Docker+Wasm, and the icon is `icon_wasm.svg` at the top level of the repository. The two samples that carry it are WasmEdge with MySQL and Nginx, described as a Wasm based web application with a static HTML frontend talking to a Wasm microservice written in Rust, and WasmEdge with Kafka and MySQL, a Wasm microservice that subscribes to a Redpanda topic and writes each message into a MariaDB database.

The consequence is that the claim has no text form. Copy the sample name into a search engine and the Wasm compatibility is gone, and a reader assembling their own list of Wasm capable samples has to recognise the icon. Only two of the twenty one multi-service samples carry it, and the single service and platform groups have no icon convention at all, so a reader looking for a Wasm option outside the first group has no signal to look for. `open_in_new.svg` in the same tree is the other piece of iconography, used on the entries that point outside the sample list.

Four entries hardcode the master branch while the rest are relative links

The single service group mixes two link styles. Angular, Spark, VueJS, Flask, PHP, Traefik, Django and FastAPI are written as relative links, and Minecraft server, Plex, Portainer and Wireguard are written as full URLs of the form `https://github.com/docker/awesome-compose/tree/master/minecraft`.

The consequence is a small but real difference in durability. A relative link resolves against whatever branch or fork you are reading, so it keeps working. A link that hardcodes `master` breaks the moment the default branch is renamed, and the default branch here is indeed `master` while other repositories in the same ecosystem have moved to `main`. The other group in the list, the third tier, uses relative links throughout, which is why the inconsistency is easy to miss when you click through the single service entries.

The naming follows the same split. The multi-service entries use backticks around the stack name inside the link text, the single service entries do not, and the Wasm entries end with a repeated link to themselves, which is how the icon is attached.

official-documentation-samples is the one folder that explains which files to create

Almost everything in the tree is a runnable directory, and one is not. `official-documentation-samples` holds quickstart guides rather than finished stacks, and the point of them is stated plainly: each step by step guide explains which files need to be created to build and run a Docker Compose application.

That is the difference that matters when you are trying to learn Compose rather than to see a stack. A runnable sample shows you the finished state of a compose.yaml and whatever sits beside it, so the reasoning behind the file is invisible. A quickstart guide walks through the creation, so the same result arrives with the decisions exposed. For a reader who has copied several of the runnable samples and cannot tell why a service has a particular key, this folder is the answer, and it is the one entry in the README that is not a list of stacks.

The top level also carries `.npmrc` and `.yarnrc.yml`, which is the tell that the documentation around these samples is maintained with Node tooling, alongside a `CONTRIBUTING.md` and a `MAINTAINERS` file.

CC0 content and no releases means there is no version to pin

The repository is licensed CC0-1.0, which dedicates the samples to the public domain rather than granting them under a software licence. Vendoring a compose file from here into your own repository raises no licence question, and equally gets you no support commitment, because there is no maintainer attached to a directory once it leaves.

The other fact to plan around is that the repository has no GitHub releases. There is no tag to pin, no changelog for the samples, and no version string inside a compose file that tells you which revision you copied. The default branch is `master`, and the last push landed on 2026-09-22, so what you read is whatever the branch holds on the day you clone it.

The consequence for a team is that tracking these samples means tracking a moving branch with no diff-friendly release notes, which is a poor fit for anything you intend to keep running. Use them to understand a shape, then own your own copy. The contribution guide exists for adding examples, and the repository welcomes submissions that help people understand how to use Docker Compose for common applications.

Editorial conclusion

Use awesome-compose to get a working multi-service Compose file in front of you in a few minutes, or to learn which files a Compose application needs from the official documentation samples folder. Do not treat any of it as a deployment base: the repository forbids production use, the third tier is labelled not production ready, and the list publishes no releases, so there is no version to pin. If you are going to run one of these stacks for real, read that sample's own compose.yaml and README.md line by line and decide for yourself what a production version would need.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository