- 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>
- Replace the relative bind mount `../homarr/appdata:/appdata` with a
named volume `homarr_appdata:/appdata` so the data survives cleanups
and can be backed up through Dokploy volume backups.
- Generate SECRET_ENCRYPTION_KEY with `${hash:64}` instead of
`${password:64}`: homarr requires a 64-character hex string
(`openssl rand -hex 32`) and the password helper emits non-hex
characters (g-z).
Closes#738
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>
The template mounted `html:/var/www/html` (freezing the app code from the
first deploy) and `data:/var/www/html/storage/data`, which misses uploaded
assets (stored under `storage/uploads`) and cache. Per the official Cockpit
persistent-storage docs, mount `config:/var/www/html/config` and
`storage:/var/www/html/storage` instead.
Closes#549
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The template pinned ghcr.io/toeverything/affine-graphql:stable-780dd83,
an ephemeral per-commit tag on the old image name that has since been
removed from GHCR, so the template could no longer pull and deploy.
- Switch both app and migration services to ghcr.io/toeverything/affine:stable,
the rolling stable tag recommended by the official self-host compose,
so the template no longer rots when per-commit tags are garbage-collected
- Move postgres to pgvector/pgvector:pg16 and set AFFINE_INDEXER_ENABLED=false,
matching the current upstream self-host compose requirements
- Add postgres/redis healthchecks and proper depends_on conditions so the
self-host-predeploy migration job runs only once the database is ready,
and the server starts only after migrations complete successfully
Closes#777
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
