- Bump image from v0.135.0-postgres to v0.162.6 (upstream dropped the
-postgres tag suffix after v0.146.0; plain tags are the postgres build)
- Remove the db-migration service: the standalone image runs database
migrations automatically on boot (auto-start-migrations), matching the
official docker-compose.prod.yml which no longer ships that service
- Generate ENCRYPTION_KEY (${hash:32}) and AUTH_SECRET (${base64:32})
per deployment instead of shipping hardcoded example secrets
- Fix SITE_URL to http://${main_domain} (no :8080; the domain is proxied)
- Refresh SMTP env names (SMTP_FROM_ADDRESS/SMTP_FROM_NAME; SMTP_SECURE
was removed upstream) and drop unused CLIENT_* env placeholders that
were never passed to the container
Closes#215
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zitadel resolves its instance from the external domain/port/scheme, so the
template's ZITADEL_EXTERNALPORT=8080 made every generated URL (OIDC issuer,
login redirects) point at http://<domain>:8080 instead of the domain served
by Traefik, ending in {"code":5,"message":"Not Found"} (#516).
- Expose ZITADEL_EXTERNALDOMAIN / ZITADEL_EXTERNALPORT / ZITADEL_EXTERNALSECURE
as template env vars, defaulting to the generated domain over HTTP
(port 80, secure=false) so the routed domain and Zitadel's external config
always match; HTTPS users flip them to 443/true in the Env tab.
- Pin image to v4.16.0 (was latest) and keep the built-in login v1 via
ZITADEL_DEFAULTINSTANCE_FEATURES_LOGINV2_REQUIRED=false so no separate
login-v2 container is needed.
- Add the official readiness healthcheck, drop the unused /app/data volume,
bogus SMTP env keys, published port and obsolete compose version key.
Closes#516
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The template set unicorn['worker_processes'] / unicorn['worker_timeout'] in
GITLAB_OMNIBUS_CONFIG. Unicorn was removed in GitLab 14.0, so on current
gitlab-ce images `gitlab-ctl reconfigure` aborts with "Removed configurations
found in gitlab.rb" and GitLab never starts serving — the generated domain
returned 502 Bad Gateway (issue #380).
Rewrite the template as the official all-in-one Omnibus setup:
- pin gitlab/gitlab-ce:19.1.2-ce.0 instead of :latest
- external_url http://<domain> with nginx listen_port 80 / listen_https false
(TLS terminates at Traefik)
- set gitlab_rails['initial_root_password'] from a generated template password
- puma single mode + prometheus monitoring off to keep memory reasonable
- drop the external postgres/redis containers (Omnibus bundles and manages
its own) and the broken ports entries ("2224" published a random host port
while sshd listens on 22)
Verified on a live Dokploy instance: domain serves the GitLab sign-in page
and root login with the generated password works.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The postgres healthcheck ran pg_isready without -U while POSTGRES_USER
was set to logto, so every probe attempted to connect as role
"postgres" and spammed FATAL: role "postgres" does not exist.
Pass -U logto -d logto explicitly and set POSTGRES_DB.
Also fix LOGTO_ENDPOINT pointing at the admin domain instead of the
main domain, update Logto 1.27.0 -> 1.41.0, use ${password:32} for the
generated password, drop the ephemeral host port publishing and add
restart policies.
Closes#130
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Kener v4 requires Redis for its BullMQ queues, caching and scheduler,
so the app crashed on startup with "REDIS_URL is not defined in
environment variables" right after printing that it was running
(issue #976). The template also spun up both a postgres and a mariadb
container while DATABASE_URL pointed at SQLite, so neither database
was ever used (issue #282).
Changes, aligned with the upstream docker-compose.yml
(rajnandan1/kener):
- Add a redis:7-alpine service with a healthcheck and persistent
volume, wire REDIS_URL=redis://redis:6379 and make kener depend on
redis being healthy
- Remove the unused postgres and mysql services plus their env vars
and generated passwords; keep SQLite (upstream default) persisted
in the kener_db volume
- Set ORIGIN to https://<domain> instead of http://localhost:3000 so
CSRF protection works behind the generated domain
- Drop the stale /app/uploads bind mount (kener v4 only persists
/app/database) and the obsolete compose version key
Deploy-tested on a Dokploy instance: migrations and seed complete,
schedulers start, "Kener version 4.1.2 is running!", HTTP 200 on the
generated domain, both containers stable.
Closes#976Closes#282
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
