* fix: remove status-page, no longer in use
* chore: remove unused domain (status-page removed)
* fix(uptimekit): pin dash 5.2.1 and clickhouse 26.8-alpine instead of latest
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(uptimekit): select the bundled ClickHouse as time-series backend
UptimeKit 5.x defaults TIMESERIES_BACKEND to timescale, which needs the
TimescaleDB extension that postgres:18-alpine doesn't ship, so dash
crash-looped. The template already bundles ClickHouse.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Mauricio Siu <siumauricio@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(senddock): report the floating image tag in template metadata
The compose file tracks ghcr.io/arkhe-systems/senddock:latest, but meta.json still
named 0.8.0 as the version. Nothing derives that field from the image, so the gallery
badge and the softwareVersion in the page metadata froze at 0.8.0 while a fresh
install already pulled 0.8.3, which reads as a template shipping a release with
defects that were fixed since.
Declaring latest matches what the other blueprints do when the image is not pinned to
a fixed tag, and it cannot drift again on the next release.
* fix(senddock): pin image to 0.8.3 and report that version
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Mauricio Siu <siumauricio@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
0.18.1 fixes GHSA-jwvh-6phv-j9jh, whose affected range this blueprint was
squarely inside: it sets STORAGE_PROVIDER=sqlite, and the advisory covers
every release from 0.8.0 through 0.18.0 on a server store.
The blueprint also seeds two accounts, admin and user. Where those two go
to different people who share a browser profile, that is the shape the
defect needs: the second to sign in received the first one's browser copy
of the workspace, with its saved connection passwords and its query
history. Both passwords come from this template's own generated secrets,
so by default the two logins belong to one deployer and nothing crosses a
privacy boundary; it is handing USER_PASSWORD to someone else that opens
it.
0.18.2 then adds a run of fixes across the PostgreSQL family, the
wire-compatible engines, MySQL, MongoDB, Redis and Oracle.
meta.json also said twenty-six drivers. Databend became a connection type
of its own in 0.18.1, where it had been reached as a relative of the MySQL
type, so the count is twenty-seven. The fifty-four named engines are
unchanged, because Databend only moved from one side of that sum to the
other.
One line is added beside the bump, because testing the upgrade turned up a
lockout the blueprint could not recover from. Since 0.18.0 ADMIN_PASSWORD
seeds the account table only while it is empty, so an operator who edits
it in Dokploy's Environment panel gets 401 on the new password while the
old one, which the panel no longer shows, still works. The app logs the
way out, "set ADMIN_PASSWORD_RESET=true and restart", but the compose
environment list is an allowlist: typing that variable into the same panel
never reached the container, so the advice could not be followed without
editing the blueprint itself. ADMIN_PASSWORD_RESET is now passed through
with an empty default. Measured on 0.18.2 with this file: empty leaves the
container with the variable defined and blank, both accounts sign in
normally and neither reset line appears in the log; with it set to true the
new password returns 200 and the old one 401; with the flag removed again
the new password keeps working. There is no USER equivalent in the
application, which the comment says, so that account is changed from
Studio's own Accounts screen.
Co-authored-by: yusuf-gundogdu <devgundogdu86@gmail.com>
* chore: remove duplicate appwrite-2 template (appwrite already provides this)
* chore: remove duplicate appwrite-2 template
The appwrite template is on 2.x (2.5.0 after #1215), so appwrite-2 is a
duplicate. The original removal was undone by a later merge of main.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Mauricio Siu <47042324+Siumauricio@users.noreply.github.com>
Co-authored-by: Mauricio Siu <siumauricio@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* feat: update appwrite template to 2.4.0 with MariaDB, node-24/26, console domain
* feat: enable DocumentsDB and VectorsDB by default in appwrite 2.4.0 template
* feat: update appwrite template to 2.4.0 with MariaDB, node-24/26, console domain
* fix(appwrite): repair 2.4.0 template structure and console setup
- Restore [config] table so config.env/config.isolated parse correctly
(the env block had been swallowed into config.mounts[0], leaving the
deployment with no environment variables)
- Add missing mongo-entrypoint.sh mount so the mongodb service can start
- Remove the mariadb [[config.domains]] entry: it exposed the DB on
main_domain and duplicated the appwrite-console route
- Route the dedicated console domain via config.domains and drop the
broken HostRegexp Traefik labels; set _APP_CONSOLE_URL/HOSTNAMES
- Bump appwrite-console image to 1.2.55-self-hosted (2.4.0 console)
- Restore the pinned appwrite-builds volume name
- Drop the removed Appwrite Assistant env/service
* feat(appwrite): apply remaining 2.4.0 hardening (clickhouse logs, browser)
- ClickHouse: add the two 2.4.0 config mounts (clickhouse-config.xml for
system-log retention, clickhouse-init.sh to backfill TTLs on existing
tables) plus CLICKHOUSE_ALWAYS_RUN_INITDB_SCRIPTS=1; the files are
generated via [[config.mounts]] and bind-mounted from ../files/
- Browser: bump appwrite/browser 0.3.4 -> 0.3.6, set ALLOWED_HOSTS=appwrite
and public DNS resolvers to block SSRF to internal services
- Bump appwrite/geo 0.3.1 -> 0.3.2 (matches 2.4.0)
* feat(appwrite): bump template to 2.5.0
Update the Appwrite blueprint to the 2.5.0 release (published
2026-10-13), which only moves images with no new environment
variables:
- appwrite/appwrite 2.4.0 -> 2.5.0 across all services
- appwrite/new console 1.2.55-self-hosted -> 1.2.74-self-hosted
- openruntimes/executor 0.29.0 -> 1.1.2
Brings project passkeys, interval-based function schedules, and
runtime containers that survive executor restarts.
---------
Co-authored-by: Mauricio Siu <47042324+Siumauricio@users.noreply.github.com>
* chore(umami): update to v3.4.0
* fix(umami): generate the database password instead of hardcoding "umami"
---------
Co-authored-by: Mauricio Siu <siumauricio@icloud.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* feat: add Cachkey template
* fix(cachkey): name the public service after the template, env as array
* fix(cachkey): unique internal API service name, APP_URL note
Single-node Wazuh 4.14.8 (manager, indexer, dashboard) adapted from the
official wazuh-docker single-node setup:
- internal TLS PKI generated on first deploy by wazuh-certs-generator into a
named volume (no host files)
- indexer internal users hashed from generated passwords before the security
index is initialized; no default credentials
- dashboard served over HTTP behind Traefik on the template domain
- agent ports 1514/1515 published on the host (raw TCP, can't go through
Traefik)
Closes#440
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Build from CopilotKit/OpenDots commit 625452e (package.json 0.1.0, upstream has
no tags yet) instead of the moving main branch, and set meta.json version to
0.1.0-625452e instead of "latest".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The template mounted the host's /var/run/tailscale, which does not exist on a
standard Dokploy server, so DockTail could never reach tailscaled. Use the
upstream sidecar setup: a pinned tailscale/tailscale container (userspace
networking, state and socket in named volumes) authenticated with
TAILSCALE_AUTH_KEY, sharing its socket with DockTail.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolves the conflicts with canary and removes the top-level version key from
the templates added since this PR was opened.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Port of #1191 (which targets main) onto canary:
- app/ and build-scripts/ dependency bumps from #1191
- signoz, timescaledb, valkey template.toml fixes from #1191
- supabase: kept canary's version (already parses under toml 4 after #1131/#1149)
- appwrite-2 (merged after #1191 was opened): escape the backslash in the
mongo entrypoint (\! -> \\!), which toml 4 rejects as an invalid escape
All 559 blueprints/*/template.toml parse with toml@4.2.0.
Co-authored-by: narcisonunez <narcisonunez@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
create-heyo-docs@0.2.3 writes "@heyo-sh/heyo-docs": "latest", which now resolves
to 3.4.1 and no longer exports heyoDocs, so astro build fails. Scaffold with
create-heyo-docs@3.1.0, pin @heyo-sh/heyo-docs@3.4.1, and set meta version.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
minio/minio images are no longer pullable. Run chrislusf/seaweedfs:4.48
as the 'minio' service with S3 on port 9000 and the same credentials, so
MINIO_ENDPOINT and the k3s ExternalName stay unchanged. Buckets are
created with weed shell in minio-init.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As offered by the author: the portal depends on a new, unpinned image of
the author's own; the base template uses only official images.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
reloopsh/* images only publish a moving 'latest' tag (fe-dashboard also has
commit tags, the rest don't), so every image is pinned to the digest of the
2026-10-06 build. meta.json version reflects that build date.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The panel's mysql client requires TLS when loading the schema
("SSL is required, but the server does not support it") and MariaDB 10.11
doesn't offer it, so migrations failed and the panel returned 500. MariaDB
11.4 enables TLS by default. Also pin hydrodactyl to v6.4.1 and redis to
7-alpine, drop the MySQL-only auth flag and wait for a healthy database.
Verified on Dokploy: panel returns 200 «Hydrodactyl», database healthy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The template shipped every S3_* variable empty while the compose requires
them, so it could never deploy. Feedbacks needs an HTTPS S3 endpoint in
production: the template now ships SeaweedFS (minio images are no longer
pullable) with a self-signed cert generated on first start and trusted via
NODE_EXTRA_CA_CERTS, plus a one-shot bucket job. External S3 can still be
used by overriding S3_*. The image digest is pinned in the compose file.
Verified on Dokploy: feedbacks returns 200, all services healthy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With a 512m heap Elasticsearch 9 still uses ~1 GiB of anonymous memory
(direct buffers, metaspace, code cache, threads), so the 1 GiB
mem_limit got it SIGKILLed in a loop on the server (no shutdown log,
restart every ~1 min). bootstrap.memory_lock made it worse by pinning
pages. Remove memory_lock/memlock ulimits and raise ES_MEM_LIMIT to
1.5 GiB while keeping the heap at 512m.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Set ES_JAVA_OPTS=-Xms512m -Xmx512m and xpack.ml.enabled=false so
Elasticsearch fits its 1 GiB mem_limit on small hosts, and give the
healthcheck a 120s start_period so a slow first boot does not abort
the depends_on chain.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"storage-${domain}" pushes the first DNS label of Dokploy's generated
sslip.io hosts past 63 characters, so the storage domain never resolves
and browser uploads can't reach it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
localhost resolves to ::1 first in the image, but Next.js listens on IPv4
0.0.0.0 only, so the healthcheck always failed and Traefik never routed to
the unhealthy container (404).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The standalone image was deployed with no database, no Redis and no config,
so celery fell back to amqp://guest@127.0.0.1:5672 and the web never came up
(502); the domain also pointed at port 3000 while the image serves on 80.
Pin pretix/standalone:2026.8.0, add postgres:16 and redis:7, configure
pretix via PRETIX_* env vars (url, secret, database, redis cache/sessions,
celery broker/backend, mail), route the domain to port 80, and set meta
version and tags.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Host port 53 is usually already bound on Dokploy servers (systemd-resolved),
so publishing 53:8053 made the deploy fail. Publish DNS on SABLE_DNS_PORT
(default 1053; set to 53 once the host port is free) so the web console
works out of the box. Pin ghcr.io/drudge/sable to the 1.6.1 release.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
busybox wget resolves localhost to ::1 first, but Nitro listens on
0.0.0.0 (IPv4 only), so the healthcheck always failed. The container
never became healthy and Traefik never routed the domain (404).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fluxer v1 images now refuse to start in production without
FLUXER_PROFILE_PSEUDONYM_SECRET (api unhealthy, users-shard crash loop).
Generate it as a template variable and pass it to all services.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MinIO images on quay.io/Docker Hub are no longer publicly pullable, so the
deploy failed at image pull. Storage now runs SeaweedFS (S3 on port 9000,
credentials orbit/MINIO_PASSWORD) and the bucket service uses mc from the
orbit-bucket image to create orbit-uploads and set its CORS rule for the
app origin (browser presigned PUT uploads).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
server and worker both mount the fresh named volume "data" at /data. The image
ships /data/media as a symlink, and when both containers are created at the same
time Docker populates the volume twice and fails with
"failed to create symlink ... /data/media: file exists". Ordering the worker
after the server makes the first-time copy happen once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Dokploy writes [[config.mounts]] files to ../files/, not next to the
compose file. ./mongo-entrypoint.sh did not exist, so Docker created an
empty directory at /mongo-entrypoint.sh and bash exited 126.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"${disabled}" is not a Dokploy helper, so ZITADEL_TLSMODE was not a valid
--tlsMode value and zitadel exited 1 on start. Default the variable to the
literal value "disabled" (users can switch it to "external" behind HTTPS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The product's own copy rule reads a numeral in front of a bare "engines" as the
count of drivers it ships, which is twenty-six. Fifty-four is the total once the
twenty-eight engines that speak an existing driver's wire protocol are counted,
so it needs the narrower noun the upstream README uses for the same figure.
Dokploy does not substitute variables in object items of an env array, so the
three [[config.env]] tables reached the container as literal ${...} and the app
started with empty ADMIN_PASSWORD, USER_PASSWORD and JWT_SECRET. The
[config.env] table form, which every other blueprint in this repo uses,
substitutes correctly. Same change as #1201.
0.18.0 is the current release. The description's engine count moves with it:
this release ships twenty-six drivers reaching fifty-four named engines,
where 0.17.0 reached forty-six.
Adds the blueprints/opendots entry for CopilotKit/OpenDots. No official
image is published, so the compose builds both app and browser targets
from the upstream repo, exposes 4310 only, and persists /data. Secrets
(OWNER_TOKEN, BROWSER_SECRET) are generated per deploy; the browser runs
without a compose profile because Dokploy does not activate profiles.
🤖 Generated with Codebuff
Co-Authored-By: Codebuff <noreply@codebuff.com>
Kaneo now ships web and API in one image (ghcr.io/usekaneo/kaneo,
API served under /api on port 5173). The old ghcr.io/usekaneo/api
image exits on start with "AUTH_SECRET is not set", so fresh
deployments of this template are broken.
- Replace backend/frontend services with the single kaneo service
- Set AUTH_SECRET and KANEO_CLIENT_URL; drop JWT_ACCESS and BACKEND_HOST
- Use one domain instead of separate frontend/backend domains
- Add healthchecks and wait for Postgres to be healthy
0.16.2 was current when this branch was last refreshed. The description also
said sixteen engines; 0.17.0 reaches eighteen, because Prometheus and Apache
Kafka were added since.
Adds the appwrite-mqtt push broker (MQTT over WebSocket on mqtt.<domain>), replaces the removed _APP_CONSOLE_URL_SCHEME with _APP_CONSOLE_URL, adds _APP_PWNED_PASSWORDS_DSN, and moves the console to 1.1.159, orchestrator to 2.2.2 and autogravity to 0.0.11 to match the stock 2.3.0 installer.
Dokploy v0.29.3 to v0.29.13 deploys templates with isolated deployment on unless the template sets isolated = false (older releases always isolate, v0.29.14+ never does by default). That mode attaches every service to an external <appName> network and never creates <appName>_default, so the orchestrator starts build jobs on a network that does not exist and the executor puts runtimes on a network of its own. The orchestrator cannot create or join networks itself, and the repo validator rejects a networks section, so the template opts out of isolation to keep the default network every service shares.
Run the headless Orca runtime (orca serve) on Dokploy. Orca publishes
no container image, so the compose builds one from the pinned upstream
release AppImage (amd64 or arm64) on Ubuntu 24.04, following the
official headless Linux server guide.
The runtime is served on one domain for both the WebSocket endpoint and
the web client. ORCA_PAIRING_ADDRESS sets the address advertised in
pairing links, and ORCA_SERVE_ARGS passes extra serve flags such as
--mobile-pairing for the Orca mobile app.
S3-compatible gateway over a POSIX backend with versioning, flat-file IAM
and the built-in WebUI exposed on the domain; S3 API and admin API ports
stay internal per the upstream Docker guide.
openruntimes-executor resolves its own container with gethostname()
against Docker's name filter. With hostname "exc1" the filter never
matches "<project>-openruntimes-executor-1", so the executor crash
loops with "Own container not found" (appwrite/appwrite#13016).
Mirror the appwrite blueprint: set hostname to the service name (a
substring of the generated container name) and point _APP_EXECUTOR_HOST
at http://openruntimes-executor/v1. Avoids container_name, which the
compose validator rejects and which is not deployment-unique.
openruntimes-executor looks itself up in Docker by matching its hostname
against the container name. Without container_name the generated name is
"<project>-openruntimes-executor-1", so the lookup fails and the executor
crash loops with "Own container not found" (appwrite/appwrite#13016),
leaving site/function deployments stuck in "building".
Add a console_domain variable (defaults to console.<main_domain>) and
route the Console, API (/v1) and Realtime (/v1/realtime) on that host,
while keeping the existing main-domain routes intact. Point
_APP_CONSOLE_DOMAIN and _APP_CONSOLE_HOSTNAMES at the console host so
the Console can reach the API on its own origin and can be protected
independently (e.g. Cloudflare Access).
Picks up the 2.1 and 2.2 releases on top of the 2.0 rebuild: console
1.1.96 self-hosted build, orchestrator 2.2.0, the autogravity service, and
the env changes from those releases (executions are ClickHouse only, the
pool adapter and legacy logging providers are gone).
Use depends_on conditions so appwrite does not start before its backing
services are healthy. Compose rejects interpolation in depends_on keys,
so postgresql is referenced by its literal service name.
Appwrite serves function/site previews on <sub>.<functionsDomain> and
<unique>.<sitesDomain>. Dokploy rejects wildcard hosts in template.toml,
so add Traefik HostRegexp labels on the appwrite service, matching the
existing appwrite blueprint.
Also disable _APP_ROUTER_AUTO_CERTIFICATES since Dokploy terminates TLS
and the bundled Appwrite Traefik is not deployed.
Add a self-hosted Appwrite 2.2 stack adapted from the official
docker-compose, using Dokploy domains instead of the bundled Traefik.
- Fix the compose file so it parses: drop the dangling networks block that
duplicated the appwrite service and created phantom gateway/runtimes
services
- Pin all images to explicit versions (appwrite/appwrite:2.2.0, etc.)
- Add restart: unless-stopped to the always-on services and to the
separate-profile workers
- Bump metabase/metabase image from v0.50.8 to v0.63.18
- Bump postgres from 14 to 16 and persist data with a named volume
- Generate the database password via the password helper instead of
hardcoding it
- Add restart policy, expose port and depends_on with healthchecks
Clearing ANON_KEY and SERVICE_ROLE_KEY is a supported mode — Envoy guards
every legacy branch — but four places broke when you did it. storage,
studio, functions and the realtime healthcheck all read the legacy pair
directly, and storage can never use an sb_ key because it calls PostgREST
at rest:3000 and never traverses the gateway. All four now resolve
${ANON_KEY:-${ANON_KEY_ASYMMETRIC}}. Verified with docker compose config
against a real deployment env: all six land on the ES256 JWTs and the
healthcheck token is non-empty.
Storage S3 block, with the three traps: REGION is read as the S3 signing
region when STORAGE_S3_REGION is unset, and this template ships it as
"stub"; STORAGE_S3_DISABLE_CHECKSUM is needed for providers that reject
the SDK's CRC32 and appears in no upstream file; GLOBAL_S3_PROTOCOL is
in the official compose and read nowhere in supabase/storage. Also noted
that imgproxy needs no S3 config — storage hands it a presigned URL.
STORAGE_TENANT_ID is the top-level key prefix, so it is permanent.
Two more warnings from a real first deploy: the domain is interpolated at
creation, so editing the Domains tab later leaves API_EXTERNAL_URL — and
therefore every token's iss — pointing at the old host; and the ES256
six-value swap does not touch the legacy pair.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three fixes found by deploying this blueprint and testing it surface by surface.
The functions service sets SUPABASE_URL to the internal gateway address, while
Auth signs tokens with API_EXTERNAL_URL as the issuer. Supabase's own edge
function JWT helper (_shared/jwt/default.ts) derives its expected issuer from
SUPABASE_URL unless SB_JWT_ISSUER is set, so it rejects every valid token with
an issuer mismatch. Passing SB_JWT_ISSUER through fixes that, and is inert for
functions that do not read it.
The ES256 procedure had three problems. It told you to clone supabase/supabase,
which is a very large monorepo, for one 7 KB script; fetching that file is
enough and node is its only requirement. It omitted --update-env, without which
only four of the six values are printed at all — ANON_KEY_ASYMMETRIC and
SERVICE_ROLE_KEY_ASYMMETRIC reach .env alone, so "replace all six with the ones
it prints" could not be followed. And the script exits 1 after writing the keys,
because it then looks for a docker-compose.yml to patch that is not there and
need not be, since this blueprint already wires all four variables; that made a
successful run look like a failure.
Also documents that pg_graphql is not installed on a fresh database, so the
/graphql/v1 route the gateway already exposes answers with an error until one
statement is run. The hosted platform ships it enabled, so this is a real
difference for code moving across.
Verified against a live deployment: the documented steps run as written, all six
values land, and the issuer now matches so edge-function JWT verification
succeeds. Blueprint validators and generate-meta --check all pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017DjX4ai6xiixeV8knW9Hpa
Appwrite 2.0 replaces the engine, ships the new root-path console and
defaults new installs to PostgreSQL, so the template is rebuilt from the
stock 2.0.0 installer output rather than bumped:
- PostgreSQL (appwrite/postgres) is the database; MariaDB/MongoDB and
their init mounts are dropped.
- Combined worker/scheduler topology (appwrite-worker, appwrite-task-scheduler)
replaces the per-queue worker containers.
- New services: orchestrator (builds), clickhouse (usage/executions),
appwrite-geo; executor bumped to 0.29.0, console to appwrite/new.
- Console is served at / with the API on /v1 and /.well-known and the
realtime server on /v1/realtime.
- Runtime and build containers join the stack's own Compose network and
the builds volume is pinned per project via COMPOSE_PROJECT_NAME.
The template generates SUPABASE_PUBLIC_URL, API_EXTERNAL_URL and
ADDITIONAL_REDIRECT_URLS with https://, which is right for a public domain with
a certificate. Dokploy creates the template's domain with none, so until one is
enabled the domain answers on http only and those three values point at a
scheme that does not respond.
Measured on a live deploy: the stack reports 11/11 healthy and the gateway
answers http with Studio's 401 basic-auth challenge, while https returns 404 —
so nothing looks broken, but Studio's own calls fail, Envoy's CORS check
compares Origin against the https string and refuses, and GoTrue builds its
issuer, OAuth redirects and email links from the dead scheme.
Also records that Let's Encrypt cannot rescue a private address: an sslip.io
name pointing at a Tailscale 100.x or a LAN address cannot be validated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A multi-agent audit of the Envoy port compared the blueprint against
supabase/supabase@master, against Dokploy's own source, and against the repo's
conventions. Three findings survived an adversarial refute pass and two more
were traced to the same cause. All five are divergences from official that
predate this branch, but they sit on the surface this branch touches.
- template.toml: API_EXTERNAL_URL gains /auth/v1, matching official
docker/.env.example:101 since supabase e7abda8d (PR #47640, 2026-07-07).
Without it GoTrue advertises https://<domain>/callback for every OAuth and
SAML flow, and Envoy's lds routes bare /callback to the `/` catch-all — that
is Studio, not auth. Measured: /auth/v1/authorize returns GoTrue's 400, while
/callback returns Studio's 401 basic-auth challenge.
- template.toml: add the /volumes/functions/deno.jsonc import map and point
main/index.ts at it, and take official's `hello` sample. Upstream shipped
these in 9ef9f1b8 (2026-08-14) and f5f897a2 (2026-08-28); the blueprint's
functions volume was still at the 2023-era deno.land/std sample with
importMapPath = null, so no function written against current Supabase docs
could resolve @supabase/server. Also injects SUPABASE_FUNCTION_SLUG.
- docker-compose.yml: restore official's SELinux flags on the shared functions
directory — `:z` not `:Z`, and `:ro` back on Studio's copy. `:Z` applies a
private MCS label, so mounting one host directory into two containers with
it revokes the first container's access on an SELinux host. Every other bind
flag in the file already matched official; these three were the only drift.
- meta.json: version becomes 2026.08.03-3. The images are unchanged from
official's 2026.08.03 snapshot, so 2026.08.17 advertised a state the template
does not ship.
- template.toml: API_GW_HTTP_PORT is inert, because the port is pinned by
`expose` and by the domain block. The comment above it said the opposite.
- instructions.md: two operational gaps the audit surfaced. Renaming kong to
api-gw makes Dokploy reject a redeploy of an existing service until the
domain's Service Name is edited. And the Postgres data directory is a bind
mount, so Dokploy's Volume Backups cannot see it, deleting the service
destroys it regardless of the delete-volumes toggle, and "redeploy with fresh
volumes" does not reset the database.
Re-verified end to end on Docker 29.4.0: all three repo validators pass, all 11
services healthy, and the eight original checks still pass. Two new ones: the
hello sample returns 200 {"message":"Hello from Edge Functions!"} for both
sb_publishable_ and sb_secret_ keys — proving the import map resolves — and
/auth/v1/settings and /auth/v1/authorize reach GoTrue.
Note a deliberate behaviour change from official: the new sample declares
auth: ["publishable","secret"], so a legacy anon JWT now gets a 401 with an
explanatory INVALID_API_KEY body where the old sample accepted it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Official Supabase made Envoy the default API gateway on 2026-08-11 (PR #48153,
self-hosted release 0.8.0) and shipped a CORS fix for /pg/ routes on 2026-08-17
(PR #49136) that only Envoy carries. This blueprint still shipped Kong.
Changes:
- docker-compose.yml: rename `kong` to `api-gw`, on envoyproxy/envoy:v1.39.0.
TCP healthcheck because the image has no curl or wget. Expose 8000 only —
Envoy has no 8443 listener. Env vars follow official: ANON_KEY /
SERVICE_ROLE_KEY replace SUPABASE_ANON_KEY / SUPABASE_SERVICE_KEY, every
KONG_* is dropped, and SUPABASE_PUBLIC_URL is added for #49136. Rename the
three internal references to the gateway, and add official's `functions`
healthcheck.
- template.toml: swap the two Kong mounts for the four envoy ones, copied from
supabase/supabase@master. serviceName becomes `api-gw`; KONG_HTTP_PORT
becomes API_GW_HTTP_PORT and KONG_HTTPS_PORT is dropped.
- meta.json: version marker names the Envoy switch.
- instructions.md: Kong replaced by Envoy in all four places, plus a note that
Studio's basic-auth credential is a SHA1+base64 hash of DASHBOARD_PASSWORD
computed by Envoy's entrypoint at startup.
Two Dokploy adaptations, deliberate and both needed:
- No `networks:` aliases block and no `ports:` mapping — validate-docker-compose
rejects both. The alias exists upstream only for backwards compatibility, and
nothing here still points at `kong`.
- cds.yaml points the realtime cluster at `realtime`, not at official's
`realtime-dev.supabase-realtime` container_name, because this blueprint sets
no container_name. lds.template.yaml is byte-identical to official, so the
Host header realtime uses for tenant resolution is unchanged.
Verified locally against Docker 29.4.0 / Compose v5.1.2, rendering the template
the way Dokploy does. All 11 services healthy; legacy keys work; sb_publishable_
is blocked by RLS while sb_secret_ reads the row; Studio basic auth challenges
and accepts; /realtime/v1/api/tenants and /realtime/v1/api/openapi return 403
and the /rest/v1/ root stays service-role only; an OPTIONS to /pg/ returns
access-control-allow-origin matching SUPABASE_PUBLIC_URL; a realtime channel
join over ?apikey=sb_publishable_… replies status ok; and the sample edge
function returns its response.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Self-hosted OpenStatus (status pages + uptime monitoring) following the
official docker-compose.github-packages.yaml setup: local libSQL database,
one-shot migration runner built from the pinned upstream commit, workflows,
API server, dashboard, status-page, and the private-location ingest server.
All app images pinned to upstream commit e1a9825; Tinybird analytics run in
no-op mode by default.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
- Force the MySQL healthcheck over TCP: with --host=localhost it pings the unix socket, which answers during MySQL's temporary init phase before networking is up, so db-import started too early and failed with connect error 111.
- Serialize the SOAP bootstrap after the admin bootstrap: both jobs insert into acore_auth.account concurrently and hit a MySQL deadlock (Error 1213) that bootstrap-account does not retry.
- Default REQUIRE_EMAIL_VERIFICATION to false via a new PORTAL_REQUIRE_EMAIL_VERIFICATION variable: the template ships empty SMTP settings, so the portal crash-looped on first deploy.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Instatic is a self-hosted, open-source visual CMS combining a canvas
editor, content engine, and static site publisher. Deployed as a
single container backed by SQLite, with uploads and DB on one
persistent volume.
Signed-off-by: Tekena Solomon <tekena157@gmail.com>
- Changed frontend, backend, livekit, and garage URLs to HTTP for sslip.io compatibility.
- Added NODE_ENV set to "development".
- Introduced optional SMTP and integration keys with placeholders.
- Added operational and security settings including rate limits and cookie configurations.
- Introduced a new template.toml file for Nebulynk blueprint.
- Defined variables for frontend, backend, LiveKit, and garage domains.
- Configured PostgreSQL and storage S3 credentials with secure password generation.
- Set up environment variables for services including JWT and API keys.
- Specified domain configurations for frontend, backend, LiveKit, and garage services.
2026-08-15 20:15:34 +02:00
602 changed files with 13060 additions and 2470 deletions
- **ALWAYS include:** `restart: unless-stopped` or `restart: always`, persistent volumes
- **Service naming:** MUST match blueprint folder name exactly
- **Example:**
- **Image source:** Prefer pinned Docker images from registries (`image: ghost:6-alpine`). When no official published images are available, use Docker Compose `build` with a Git context (e.g., `context: "https://github.com/..."#main`, see `blueprints/opendots` for an example building both `app` and `browser` targets from the upstream repository).
- **Example (with pinned image):**
```yaml
version: "3.8"
services:
ghost:
image: ghost:6-alpine
@@ -162,7 +161,7 @@ This document provides essential context for AI models interacting with this pro
- **Version:** MUST match Docker image version in docker-compose.yml
- **Version:** MUST match Docker image version in docker-compose.yml when using `image:`. When building from source (using `build:` with a Git context), the version should reflect the template's own version or the upstream project's version (e.g., `"latest"` for tracking `main` branch).
- **Logo:** Filename only (e.g., `"ghost.jpeg"`), file must exist in blueprint folder
- **Frontend Development:**
@@ -183,8 +182,8 @@ This document provides essential context for AI models interacting with this pro
- **Dependencies:**
- When adding new templates, ensure Docker images are pinned to specific versions
- Update meta.json with exact version matching Docker Compose image version
- When adding new templates, prefer pinned Docker images to specific versions when available
- Update meta.json with exact version matching Docker Compose image version (for `image:`), or the template/upstream version (for `build:` from source)
- For frontend dependencies: Use `pnpm add <package>` in `app/` directory
- For root dependencies: Use `npm install <package>` in root directory
<metaname="description"content="Browse 500+ open source Docker templates and one-click self-hosted apps to deploy with Dokploy – databases, CMS, analytics, AI tools and more."/>
<metaproperty="og:title"content="Dokploy Templates: 500+ Open Source Apps"/>
<metaproperty="og:description"content="Browse 500+ open source Docker templates and one-click self-hosted apps to deploy with Dokploy – databases, CMS, analytics, AI tools and more."/>
<metaname="twitter:title"content="Dokploy Templates: 500+ Open Source Apps"/>
<metaname="twitter:description"content="Browse 500+ open source Docker templates and one-click self-hosted apps to deploy with Dokploy – databases, CMS, analytics, AI tools and more."/>
<title>Dokploy Templates: 500+ Open Source Apps</title>
"description":"Self-hosted AI model router that rotates requests across 40+ providers with automatic fallback, exposing an OpenAI-compatible endpoint for coding agents.",
# dokploy: allow-host-ports — DNS (53/tcp+udp), DHCP (67/68) and DNS-over-TLS/QUIC (853) are not HTTP protocols; clients must reach them directly on the host, Traefik cannot route them.
"description":"AdGuard Home is a comprehensive solution designed to enhance your online browsing experience by eliminating all kinds of ads, from annoying banners and pop-ups to intrusive video ads. It provides privacy protection, browsing security, and parental control features while maintaining website functionality.",
"description":"AdGuard Home is a network-wide ad and tracker blocker. Self-host it on your own server with Dokploy, which deploys AdGuard Home as a Docker Compose service in a few clicks.",
"seoDescription":"Network-wide ad and tracker blocker. Deploy AdGuard Home with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
"description":"Adminer is a comprehensive database management tool that supports MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch, MongoDB and others. It provides a clean interface for efficient database operations, with strong security features and extensive customization options.",
"description":"Adminer is a lightweight, web-based database management tool. Self-host it on your own server with Dokploy, which deploys Adminer as a Docker Compose service in a few clicks.",
"logo":"logo.svg",
"links":{
"github":"https://github.com/vrana/adminer",
@@ -14,5 +14,8 @@
"developer-tools",
"mysql",
"postgresql"
]
],
"seoTitle":"Adminer Docker Compose Setup",
"seoDescription":"Lightweight database management tool. Deploy Adminer with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
"description":"Affine Pro is a modern, self-hosted platform designed for collaborative content creation and project management. It offers an intuitive interface, seamless real-time collaboration, and powerful tools for organizing tasks, notes, and ideas.",
"description":"AFFiNE is a workspace for notes, docs, and whiteboards, and an alternative to Notion. Self-host it on your own server with Dokploy, which deploys AFFiNE as a Docker Compose service in a few clicks.",
"description":"AnythingLLM is a private, self-hosted, and local document chatbot platform that allows you to chat with your documents using various LLM providers.",
"description":"AnythingLLM is a private AI chat app for working with your own documents. Self-host it on your own server with Dokploy, which deploys AnythingLLM as a Docker Compose service in a few clicks.",
"description":"Anytype is a personal knowledge base—your digital brain—that lets you gather, connect and remix all kinds of information. Create pages, tasks, wikis, journals—even entire apps—and define your own data model while your data stays offline-first, private and encrypted across devices.\n\nAfter installation, you can view the Anytype client configuration by running `cat /data/client-config.yml` inside the service container.",
"description":"Anytype is a private, offline-first app for notes and personal knowledge. Self-host it on your own server with Dokploy, which deploys Anytype as a Docker Compose service in a few clicks.",
"seoDescription":"Private, offline-first personal knowledge base. Self-host Anytype on Dokploy – view your client config afterward with a quick command inside the container."
"description":"AppFlowy is an open-source alternative to Notion. You are in charge of your data and customizations.",
"description":"AppFlowy is a workspace app for notes, docs, and projects, and an open-source alternative to Notion. Self-host it on your own server with Dokploy, which deploys AppFlowy as a Docker Compose service in a few clicks.",
"description":"Appwrite is an end-to-end platform for building Web, Mobile, Native, or Backend apps, packaged as a set of Docker microservices. It includes both a backend server and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite abstracts the complexity and repetitiveness required to build modern apps from scratch and allows you to build secure, full-stack applications faster.\nUsing Appwrite, you can easily integrate your app with user authentication and multiple sign-in methods, a database for storing and querying users and team data, storage and file management, image manipulation, Cloud Functions, messaging, and more services.",
"description":"The Single Sign-On Multi-Factor portal for web apps. An open-source authentication and authorization server providing 2FA and SSO via web portal.",
"description":"Authelia is an open-source authentication portal for single sign-on (SSO) and two-factor authentication. Self-host it on your own server with Dokploy, which deploys Authelia as a Docker Compose service in a few clicks.",
"logo":"authelia.png",
"links":{
"github":"https://github.com/authelia/authelia",
@@ -17,5 +17,8 @@
"security",
"reverse-proxy",
"ldap"
]
],
"seoTitle":"Authelia Docker Compose Setup",
"seoDescription":"Single sign-on and two-factor auth portal. Deploy Authelia with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
"description":"Authentik is an open-source Identity Provider for authentication and authorization. It provides a comprehensive solution for managing user authentication, authorization, and identity federation with support for SAML, OAuth2, OIDC, and more.",
"version":"2026.8.2",
"description":"Authentik is an identity provider for single sign-on (SSO) authorization and authentication, with support for SAML, OAuth2, OIDC, and more. Self-host it on your own server with Dokploy, which deploys Authentik as a Docker Compose service in a few clicks.",
"seoDescription":"Identity provider for SSO and authentication. Deploy Authentik with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
AzerothCore's published server images currently support `amd64` hosts only.
AzerothCore uses raw TCP connections rather than HTTP. Make sure TCP ports `3724` (authentication) and `8085` (world server) are free on the Dokploy host and allowed through its firewall.
The template generates `REALM_ADDRESS` with Dokploy's domain helper. Verify that this hostname resolves publicly to the Dokploy server. If it does not, replace `REALM_ADDRESS` in the service environment with the server's public IP address or another public DNS name, then redeploy.
## First startup
The first deployment downloads the client data and imports the authentication, character, and world databases. This can take several minutes. The `azerothcore-client-data`, `azerothcore-db-import`, and `azerothcore-realm-config` containers are initialization jobs and should exit successfully after completing their work.
## Create the first game account
After the `azerothcore` world server is running, attach to its console from the Dokploy host:
Create an account and grant it administrator permissions:
```text
account create <username> <password>
account set gmlevel <username> 3 -1
```
Detach without stopping the server by pressing `Ctrl-p`, then `Ctrl-q`.
## Connect a 3.3.5a client
Set the client's `Data/<locale>/realmlist.wtf` file to the same hostname or IP stored in `REALM_ADDRESS`:
```text
set realmlist <REALM_ADDRESS>
```
Restart the client, sign in with the account created above, and select the AzerothCore realm. If authentication works but the realm connection fails, confirm that TCP port `8085` is reachable and that `REALM_ADDRESS` points to the Dokploy host.
For updates, backups, configuration, and troubleshooting, see the [AzerothCore Docker documentation](https://www.azerothcore.org/wiki/install-with-docker).
"description":"BookStack is a self-hosted platform for creating beautiful, feature-rich documentation sites.",
"description":"BookStack is a wiki platform for organizing documentation. Self-host it on your own server with Dokploy, which deploys BookStack as a Docker Compose service in a few clicks.",
"seoDescription":"Platform for building documentation wikis. Deploy BookStack with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
"description":"Cachkey is an open-source, self-hosted manager for secrets and environment variables: encrypted values, per-environment access for your team, a CLI and a read-only API for servers and CI.",
"description":"Calcom is a open source alternative to Calendly that allows to create scheduling and booking services.",
"description":"Cal.com is a scheduling and booking tool and an alternative to Calendly. Self-host it on your own server with Dokploy, which deploys Cal.com as a Docker Compose service in a few clicks.",
"links":{
"github":"https://github.com/calcom/cal.com",
"website":"https://cal.com/",
@@ -12,5 +12,7 @@
"tags":[
"scheduling",
"booking"
]
],
"seoTitle":"Self-Host Cal.com in minutes",
"seoDescription":"Scheduling and booking tool, an alternative to Calendly. Self-host Cal.com on Dokploy in minutes – no manual setup needed."
"description":"Calibre-Web is a web app providing a clean interface for browsing, reading, and managing your eBooks library using an existing Calibre database.",
"description":"Calibre-Web is a web interface for browsing, reading, and downloading ebooks from a Calibre library. Self-host it on your own server with Dokploy, which deploys Calibre-Web as a Docker Compose service in a few clicks.",
"seoDescription":"Web interface for browsing your ebook library. Deploy Calibre-Web with Docker Compose on Dokploy – requires an existing Calibre database.",
"description":"Open-source customer engagement platform that provides a shared inbox for teams, live chat, and omnichannel support.",
"description":"Chatwoot is an open-source customer support and engagement platform with a shared inbox and live chat. Self-host it on your own server with Dokploy, which deploys Chatwoot as a Docker Compose service in a few clicks.",
"logo":"chatwoot.svg",
"links":{
"github":"https://github.com/chatwoot/chatwoot",
@@ -13,5 +13,7 @@
"support",
"chat",
"customer-service"
]
],
"seoTitle":"Self-Host Chatwoot in minutes",
"seoDescription":"Shared inbox and live chat for customer support. Self-host Chatwoot on Dokploy in minutes – no manual setup needed."
"description":"ClickHouse is an open-source column-oriented DBMS (columnar database management system) for online analytical processing (OLAP) that allows users to generate analytical reports using SQL queries in real-time. ClickHouse works 100-1000x faster than traditional database management systems, and processes hundreds of millions to over a billion rows and tens of gigabytes of data per server per second.",
"description":"ClickHouse is a fast, open-source columnar database built for real-time analytics. Self-host it on your own server with Dokploy, which deploys ClickHouse as a Docker Compose service in a few clicks.",
"seoDescription":"Fast columnar database for analytics. Deploy ClickHouse with Docker Compose on Dokploy in minutes – free, open source, self-hosted.",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.