Lines 11 and 65 still told contributors to add their entry to the root
meta.json, which was removed in #978 (metadata now lives in
blueprints/<id>/meta.json and the aggregate is generated at build time).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- gel: allow plain HTTP for the reverse proxy (GEL_SERVER_HTTP_ENDPOINT_SECURITY=optional), enable admin UI and point the domain at /ui
- keydb: remove HTTP domain and published port — pure Redis-protocol DB reachable via internal network
- leantime: image serves on 8080 (non-root nginx), add required LEAN_APP_URL and LEAN_SESSION_PASSWORD, use utf8mb4
- matomo: removed from this PR, already fixed in #765
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- chroma: mount volume at /data (chromadb 1.x data dir), drop legacy 0.x
env vars (IS_PERSISTENT/PERSIST_DIRECTORY) and point the domain to
/api/v2/heartbeat so the API-only service verifies with HTTP 200
- homebox: newer images panic on boot without HBOX_AUTH_API_KEY_PEPPER
(>=32 bytes); generate it via ${password:64} in template.toml
- languagetool: point the domain to /v2/languages (the API returns 400
on "/"), which responds HTTP 200
- restore gotify/jellyseerr/privatebin/speedtest-tracker meta.json to
canary so this PR no longer touches templates that already exist
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Multica backend is an API-only chi server with no route registered
at "/", so the generated backend domain (path "/") permanently answered
HTTP 404 even though the container was healthy. The web frontend already
proxies /api/*, /ws, /auth/* and /uploads/* to http://backend:8080 via
Next.js rewrites, and when NEXT_PUBLIC_WS_URL is unset the browser
derives the WebSocket URL from the page origin, so the backend never
needs to be exposed publicly.
- drop the backend [[config.domains]] entry and api_domain variable
- drop NEXT_PUBLIC_WS_URL so the WS URL falls back to the page origin
and goes through the frontend's /ws rewrite
- remove ephemeral host port publications (ports: "8080"/"3000");
Traefik reaches the containers over the docker network
Verified on a Dokploy instance: deploy done, frontend / -> 200 and
backend reachable through the proxy (/api/config -> 200).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The deploy failed with 'dependency failed to start: container db-1 is
unhealthy'. Root cause: the MariaDB 11.8 healthcheck allowed only ~40s
(start_period 10s + 3x10s retries) before flagging the container
unhealthy, which is not enough for the first-boot datadir
initialization on a modest VPS. Since create-site depended on
db:service_healthy, docker compose up -d aborted the whole deploy.
Fixes, following the pattern of the existing working erpnext template:
- Extend the db healthcheck window (start_period 120s, 30 retries) so
first-boot initialization does not mark the container unhealthy.
- Drop depends_on from the one-shot create-site and migration jobs and
gate create-site with wait-for-it (db/redis) inside its command, so
docker compose up -d returns without blocking on the multi-minute
site creation and cannot fail on transient health states.
Verified on a fresh deploy: all services up, create-site installed
frappe + erpnext and enabled the scheduler, frontend serves the
ERPNext login page with HTTP 200.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bootstrap died with exit 2 because Composer >= 2.9 enables
audit.block-insecure by default: shopware/core v6.7.8.2 is now affected
by 9 security advisories (all fixed in 6.7.10.1+), so
'composer create-project shopware/production:6.7.8.2' failed to resolve
dependencies and the whole stack never started.
- Bump the pinned Shopware version to 6.7.12.1 (latest, advisory-free).
- Disable audit.block-insecure in the bootstrap's global composer config
so advisories published after a version is pinned cannot brick fresh
one-click deploys.
- Use APP_URL=http://${main_domain} per template conventions; an https
APP_URL breaks storefront sales-channel matching when the Dokploy
domain is served over plain http.
Verified on a Dokploy instance: full bootstrap + deployment-helper
install completed in ~4 min, storefront and /admin both return HTTP 200.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The --password flag makes Glances prompt for a password interactively
via getpass, which fails in a non-TTY container. The container kept
crash-looping, so Traefik returned 404 for the domain. Glances also
does not read GLANCES_USERNAME/GLANCES_PASSWORD env vars, so the auth
setup was ineffective. Run the web server with GLANCES_OPT=-w and drop
the unused password env vars from the compose file and template.toml.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
FORCE_SSL=true + FRONTEND_URL=https:// made Rails 301-redirect every
request to https, which Traefik answered with a sustained 404 because
Dokploy-generated template domains are http-only. Default to
FORCE_SSL=false and FRONTEND_URL=http://${main_domain} (matching the
repo convention); users who terminate TLS can flip these afterwards.
Verified on a Dokploy instance: fresh deploy of chatwoot/chatwoot:v4.12.1
migrates and answers HTTP 200 with the onboarding page.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The official postgres:18 image moved PGDATA from /var/lib/postgresql/data
to /var/lib/postgresql. Mounting the volume at the old path made the
entrypoint abort and the postgresql container restart-loop, failing the
deploy with "dependency postgresql failed to start". Mounting the volume
at /var/lib/postgresql fixes the deploy; server responds 200 on
/if/flow/initial-setup/.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The compose file referenced ${SERVICE_PASSWORD_ENCRYPT} and
${SERVICE_PASSWORD_WEB}, but template.toml defines the variables as
SETTINGS_ENCRYPTION_KEY and DUPLICATI__WEBSERVICE_PASSWORD, so both
values rendered empty at deploy time. Also removed the leftover
SERVICE_URL_DUPLICATI_8200 passthrough entry and added
DUPLICATI__WEBSERVICE_ALLOWED_HOSTNAMES=* so the Duplicati web server
(2.0.8+) accepts requests forwarded by Traefik for the configured
domain instead of rejecting unknown Host headers.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The template pointed PS_DATA_SOURCE_URI at a placeholder connection
string (postgresql://user:password@host:5432/db), so the PowerSync
service could never connect and crash-looped, leaving the domain
returning Traefik 404s.
Changes:
- Add a bundled Postgres 17 service with wal_level=logical, a
healthcheck, and a persistent volume; powersync waits for it to be
healthy before starting.
- Replace the base64-encoded config env var with a readable
powersync.yaml mounted via [[config.mounts]]. Replication reads from
the powersync database and bucket storage uses a separate
powersync_storage database (Postgres storage requires a database
distinct from the replication source).
- Add an init SQL mount that creates the storage database, a demo
"lists" table synced by the default sync rules, and the powersync
publication required for logical replication.
- Replace the unsupported sync_config block with standard sync_rules,
and add an HS256 dev key so client auth works out of the box.
- Remove host port mapping (Traefik routes to the container port) and
point the template domain at /probes/liveness since PowerSync has no
route on "/".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The postgres:18-alpine image moved PGDATA from /var/lib/postgresql/data
to /var/lib/postgresql, so mounting the volume at the old path made the
entrypoint abort and the db container restart forever, failing the
service_healthy dependency for dash and status-page.
- Mount db_data at /var/lib/postgresql (postgres 18 layout)
- Remove host port mappings (Dokploy routes via domains/Traefik)
- Generate POSTGRES_PASSWORD and CLICKHOUSE_PASSWORD with ${password:32}
instead of hardcoded credentials
- Drop unused DASH_PORT/STATUS_PAGE_PORT env and dangling empty
[[config.mounts]] section in template.toml
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The tb-node image runs as the non-root "thingsboard" user (uid 799), but
the freshly created /data named volume is owned by root, so
"touch /data/.thingsboard-installed" failed with permission denied after
every successful install. Combined with "set -e" and "restart: on-failure",
the init container kept re-running the installer forever and the main
thingsboard service (gated on service_completed_successfully) never
started, leaving the domain returning 404.
Running the init service as root lets the marker be written so the init
completes and stays idempotent across redeploys. Also widened the main
service healthcheck start window (start_period 300s, retries 10) so the
slow first boot on modest VPS hardware is not marked unhealthy while
docker compose up --wait is in progress.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The postgres:18 image moved its data directory from
/var/lib/postgresql/data to /var/lib/postgresql, and its entrypoint
now fails hard when a volume is mounted at the old path. This made
paperless-ngx-db restart-loop and never reach healthy, so the deploy
errored with 'dependency paperless-ngx-db failed to start'.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The container was restart-looping because the built-in IdP fatals with
"invalid iss value, URL must start with https://" when OCIS_URL uses
plain http, which caused the sustained 502.
- Set owncloud_url to https://${main_domain} so the IdP issuer is valid
and ocis server stays up.
- oCIS 8.x unconditionally answers 308 -> https:// whenever it receives
X-Forwarded-Proto: http (services/proxy https_redirect middleware), so
the domain check then died on a redirect loop into a non-existent 443
router. Add a small nginx gateway in front of oCIS that forwards
requests with X-Forwarded-Proto: https (what a TLS-terminating proxy
sends) and point the Dokploy domain at gateway:8080.
- Update the README notes accordingly.
Verified on a live Dokploy instance: deploy done, GET / returns
HTTP 200 with title "ownCloud".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
NodeLink requires the Authorization header on every API route,
including /version, so the healthcheck's unauthenticated fetch always
got a 401 and the container stayed permanently unhealthy. Traefik
skips unhealthy containers, so the assigned domain returned a
sustained 404 even though the deploy finished successfully.
Pass the container's NODELINK_SERVER_PASSWORD as the Authorization
header in the healthcheck fetch; the container now reaches a healthy
state and the domain routes to the server (401 on / without
credentials, 200 on /version with the password), as expected for a
Lavalink-compatible server.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
evolutioncrm:
- Point the evo-crm-frontend domain at port 80 instead of 5173: the
community frontend image serves the built app via nginx on port 80
(5173 is the vite dev port), so the domain returned 502.
- Set EVOLUTION_API_ONLY_SERVER=true on evo-crm: the community image
ships without the Rails dashboard views (the UI lives in the separate
evo-crm-frontend service), so the default root route (dashboard#index)
can never render and returned 406 for every request. With the flag the
root serves the API status JSON; all /api routes are unaffected.
- Drop the evolution-go-* volumes that were left over from the other
template.
evolutiongo:
- Evolution GO has no route on "/" and answers 503 (LICENSE_REQUIRED)
on API routes until a license is activated through the bundled
manager UI, so the single domain never responded. Add a small nginx
gateway that redirects "/" to /manager/login and proxies everything
else (WebSockets included) 1:1 to evolution-go:8080, and point the
domain at it.
- Persist /app/dbdata and /app/logs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The named volume mounted at /home/coder/.config was created root-owned
(the path does not exist in the codercom/code-server image), so
code-server running as uid 1000 failed with
"EACCES: permission denied, mkdir '/home/coder/.config/code-server'"
and restarted in a loop, leaving Traefik returning 404. The .config
directory already lives inside /home/coder, which is persisted by the
code-server-home volume, so the extra volume is unnecessary.
Verified: deploy done, container healthy, domain on port 8080 returns
HTTP 200 with the code-server login page.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The template deployed but returned a persistent HTTP 500: MARIADB_DATABASE
pre-created the wallabag database, so the image entrypoint detected an
existing database, skipped bin/console wallabag:install and left an empty
schema. Only MARIADB_ROOT_PASSWORD is set now, letting the entrypoint
create the database/user and run the installer on first boot (matching the
official wallabag docker-compose).
Also:
- build SYMFONY__ENV__DOMAIN_NAME from the generated domain with the http
scheme so assets/redirects match how the domain is served
- point SYMFONY__ENV__REDIS_HOST at the wallabag-redis service (default is
'redis', which does not resolve here)
- randomize SYMFONY__ENV__SECRET instead of relying on the image's
hardcoded default
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Reword two docker-compose comments so the literal string
"dokploy-network" no longer appears. The compose never declared the
network manually (Dokploy attaches it automatically); the automated
template check was tripping on the comment text alone.
- meta.json: keep canary's richer description and tags
(kanban, project-management), bumping only the version to v1.3.1.
Deploy-verified on a test Dokploy instance: full stack booted in 465s
and proxy:80 answered HTTP 200 with the Plane landing page.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zulip 12 rejects requests forwarded by an untrusted reverse proxy with
a 500 "Proxy-Misconfiguration: Incorrect reverse proxy IPs set in
Zulip" error page. TRUST_GATEWAY_IP=True only whitelists the
container's default-route gateway IP, but Dokploy's Traefik connects
from its own container IP on the (dynamically-subnetted) compose
network, so it was never trusted.
Replace TRUST_GATEWAY_IP with LOADBALANCER_IPS covering the RFC1918
ranges, which Zulip feeds into nginx set_real_ip_from / its trusted
proxy list, so Traefik is trusted regardless of which Docker subnet it
connects from.
Also align meta.json version with the shipped image tag (12.1-0).
Note: the zulip-server image ships a HEALTHCHECK (/health, 300s start
period) and first boot runs full migrations, so Traefik only exposes
the router once the container turns healthy — expect several minutes
of 404 on the domain right after the first deploy.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
