Docs
Templates
146 one-click compose stacks across 15 categories, plus your own catalogs.
Categories
- Apps, CMS, Productivity, Analytics, Monitoring, Media
- Knowledge, Notifications, Finance, Developer Tools, Databases
- AI, Communication, Security, Storage
Deploy flow
Pick a template → choose project / environment → fill env vars (secrets auto-generated where marked) → optional domain → Deploy. After deploy you own the compose file and can edit it freely.
Some templates declare the hostnames they need — a tunnel edge's endpoint host, the zone its tunnels are served under. Those are read from the env values you type and attached as domains of the stack on deploy (HTTPS with Let's Encrypt; a wildcard is instance-admin only and gets its certificate over DNS-01 when a provider is linked). The Domain step previews them, a value left at the placeholder attaches nothing, and with automatic DNS records on the A records are created at your provider too.
Template images are checked in CI for registry availability. Templates that need host privileges (a mounted Docker socket, extra capabilities) can only be deployed and later edited by the instance admin.
MinIO compiles its pinned official source release on first start using the official Go image. Allow several minutes, memory headroom and about 2.3 GB of extra disk for the persistent build cache; a local 2 CPU / 1 GiB test took 73 seconds with modules downloaded and used the full memory limit. The first start needs internet access for Go modules and checksum verification. Objects remain in minio-data; minio-build caches the compiler output for later starts. Authentik uses the pinned 2026.8.4 server and worker, PostgreSQL without Redis, and /data for media. Existing saved compose files are not changed by a template update; check upstream upgrade notes before updating an older stack.
Bring your own catalog
The built-in catalog ships with the image, so it only changes with a release. Settings → Templates adds your own sources, scoped to one organization and managed by an org admin or owner.
- http-json — one JSON document: a bare array of templates, or { templates: [ … ] }
- git — a repository whose templates/index.json has the same shape, cloned shallow and discarded
- coolify — a generated templates/service-templates.json URL with Base64 Compose entries; the official URL is prefilled in Settings → Templates. Supports one public service target, named volumes, documented random generators and required inputs. Each installation gets fresh credentials; redeploys keep saved values. Unsupported entries appear with a reason in the sync report.
- blueprints — a repository laid out as blueprints/<id>/{meta.json, template.toml, docker-compose.yml}, the Dokploy templates catalog format; each blueprint is translated (helpers become deploy-time placeholders, file mounts become inline configs, env_file becomes environment entries, routing labels are dropped, tags are resolved to the catalog's own categories instead of becoming 209 one-off ones) and run through the compose safety checks, so 436 of the 532 public entries deploy as-is and the rest are listed with their reason
- Nothing is fetched while browsing: Sync now does the work and caches the result on disk with mode 0600
- A bad entry is dropped with a reason rather than taking the whole catalog offline; an image tag that cannot be confirmed anonymously is a warning, not a rejection; a template that publishes host ports is indexed and flagged, and deploying it creates the stack with port publishing on (instance admin only)
- Remote ids are namespaced by their source, so a source can never shadow a built-in template, and hostPrivileged is never accepted from a remote catalog
- Coolify FQDN values are hostnames and URL values initially use HTTP. Domain-dependent templates need a domain at installation. After enabling HTTPS, update saved URL values; legacy upstream templates may need their FQDN references changed to full URLs. Multiple public targets, domain paths, inline file mounts, health exclusions and unsupported magic variables require manual setup. Indexed entries still need application-level testing; existing data is not imported.
Deploy from a compose URL
A raw compose file at an http(s) URL can be turned straight into a compose service. The URL goes through the same outbound guard as everything else, the body through the same safety checks a pasted file gets, and nothing is deployed until you say so. Give it the raw file URL — redirects are not followed, and an HTML response (a repository page instead of the raw file) is rejected with that message.
Also see the repository guides under docs/ · REST API reference
