Compose Anything

Compose Anything helps users quickly deploy various services by providing a set of high-quality Docker Compose configuration files. These configurations constrain resource usage, can be easily migrated to systems like K8S, and are easy to understand and modify.

Supported Services

Service	Version
Apache APISIX	3.13.0
Apache Cassandra	5.0.2
Apache HTTP Server	2.4.62
Apache Kafka	7.8.0
Bifrost Gateway	1.2.15
Bytebot	edge
Clash	1.18.0
Dify	0.18.2
DNSMasq	2.91
Docker Registry	3.0.0
Elasticsearch	8.16.1
etcd	3.6.0
frpc	0.64.0
frps	0.64.0
Gitea Runner	0.2.12
Gitea	1.24.6
GitLab Runner	17.10.1
GitLab	17.10.4-ce.0
GPUStack	v0.5.3
Grafana	12.1.1
Halo	2.21.9
Harbor	v2.12.0
HashiCorp Consul	1.20.3
IOPaint	latest
Jenkins	2.486-lts
Kibana	8.16.1
Kodbox	1.62
Kong	3.8.0
Langfuse	3.115.0
LiteLLM	main-stable
Logstash	8.16.1
Milvus Standalone Embed	2.6.2
Milvus Standalone	2.6.2
MinerU SGALNG	2.2.2
MinerU v2	2.5.3
MinIO	RELEASE.2025-09-07T16-13-09Z
MongoDB ReplicaSet	8.0.13
MongoDB Standalone	8.0.13
MySQL	9.4.0
n8n	1.114.0
Nacos	v3.1.0
NebulaGraph	v3.8.0
Neo4j	5.27.4
Nginx	1.29.1
Node Exporter	v1.8.2
Odoo	19.0
Ollama	0.12.0
Open WebUI	main
OpenCoze	See Docs
OpenCut	latest
OpenList	latest
Portainer	2.27.3-alpine
PocketBase	0.30.0
PostgreSQL	17.6
Prometheus	3.5.0
Qdrant	1.15.4
RabbitMQ	4.1.4
Redis Cluster	8.2.1
Redis	8.2.1
SearXNG	2025.1.20-1ce14ef99
Verdaccio	6.1.2
vLLM	v0.8.0
ZooKeeper	3.9.3

Guidelines

1. Out-of-the-box
   • Configurations should work out-of-the-box with no extra steps (at most, provide a .env file).
2. Simple commands
   • Each project ships a single docker-compose.yaml file.
   • Command complexity should not exceed docker compose up -d; if more is needed, provide a Makefile.
   • For initialization, prefer healthcheck with depends_on using condition: service_healthy to orchestrate startup order.
3. Stable versions
   • Pin to the latest stable version instead of latest.
   • Expose image versions via environment variables (e.g., FOO_VERSION).
4. Configuration conventions
   • Prefer environment variables over complex CLI flags;
   • Pass secrets via env vars or mounted files, never hardcode;
   • Provide sensible defaults to enable zero-config startup;
   • A commented .env.example is required;
   • Env var naming: UPPER_SNAKE_CASE with service prefix (e.g., POSTGRES_*); use *_PORT_OVERRIDE for host port overrides.
5. Profiles
   • Use Profiles for optional components/dependencies;
   • Recommended names: gpu (acceleration), metrics (observability/exporters), dev (dev-only features).
6. Cross-platform & architectures
   • Where images support it, ensure Debian 12+/Ubuntu 22.04+, Windows 10+, macOS 12+ work;
   • Support x86-64 and ARM64 as consistently as possible;
   • Avoid Linux-only host paths like /etc/localtime and /etc/timezone; prefer TZ env var for time zone.
7. Volumes & mounts
   • Prefer relative paths for configuration to improve portability;
   • Prefer named volumes for data directories to avoid permission/compat issues of host paths;
   • If host paths are necessary, provide a top-level directory variable (e.g., DATA_DIR).
8. Resources & logging
   • Always limit CPU and memory to prevent resource exhaustion;
   • For GPU services, enable a single GPU by default via deploy.resources.reservations.devices (maps to device requests) or gpus where applicable;
   • Limit logs (json-file driver: max-size/max-file).
9. Healthchecks
   • Every service should define a healthcheck with suitable interval, timeout, retries, and start_period;
   • Use depends_on.condition: service_healthy for dependency chains.
10. Security baseline (apply when possible)
    • Run as non-root (expose PUID/PGID or set user: "1000:1000");
    • Read-only root filesystem (read_only: true), use tmpfs/writable mounts for required paths;
    • Least privilege: cap_drop: ["ALL"], add back only what’s needed via cap_add;
    • Avoid container_name (hurts scaling and reusable network aliases);
    • If exposing Docker socket or other high-risk mounts, clearly document risks and alternatives.
11. Documentation & discoverability
    • Provide clear docs and examples (include admin/initialization notes, and security/license notes when relevant);
    • Keep docs LLM-friendly;
    • List primary env vars and default ports in the README, and link to README.md / README.zh.md.

License

MIT License.