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 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 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>
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 filerun/filerun image runs as user filerun (1001:1001), but /var/www/html
is created as root in the image, so the named volume inherits root:root
ownership. The entrypoint's first-run installer then fails to download
filerun.zip into /var/www/html (Permission denied) and the container
crash-loops with exit 1.
- Add a busybox init service that chowns the html and user-files volumes to
1001:1001 before filerun starts (gated via service_completed_successfully).
- Drop the user: "99:100" override, which is meant for pre-chowned host bind
mounts in the upstream example, not named volumes.
- Remove the UTF-8 BOM at the start of the file, the legacy links: entry and
the obsolete version: key.
Verified on a live Dokploy deploy: HTTP 200 with page title
"FileRun :: Installation".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The vabene1111/recipes 2.x image starts gunicorn on unix:/tmp/tandoor.sock
unless TANDOOR_PORT is set, so Traefik got 502. Set TANDOOR_PORT=8080 and
point the domain to 8080 (80 was never listening).
Deploy-tested on a Dokploy instance: HTTP 200, setup page renders.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- move each template's metadata to blueprints/<id>/meta.json (442 files, byte-identical roundtrip with the old root meta.json)
- generate the served meta.json at build time into app/public/meta.json (gitignored); pnpm dev/build run the generator first
- CI validates every blueprints/<id>/meta.json via generate-meta.js --check (required fields, id/folder match, logo exists, folder<->meta bidirectionality) and rejects any committed root meta.json
- remove root meta.json, dedupe-and-sort-meta.js and build-scripts/process-meta.js (obsolete)
- update CONTRIBUTING.md, AGENTS.md and README.md
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(plane): update template to Plane v1.x (stable)
The existing template targeted v0.27.1 which is heavily outdated.
This updates it to match Plane's current official deployment config.
Changes:
- Images: v0.27.1 → stable (currently v1.2.3) from Docker Hub
- Remove explicit commands from frontend services (built into images)
- Postgres: 17-alpine → 15.7-alpine (matches Plane's supported version)
- Valkey: 7.2.5 → 7.2.11
- Proxy: add admin + live dependencies, proxy_config/proxy_data volumes
- Add LIVE_SERVER_SECRET_KEY, APP_DOMAIN, SITE_ADDRESS env vars
- Add RABBITMQ_USER/PASSWORD/VHOST (new v1.x env var names)
- Fix RABBITMQ_DEFAULT_USER bug (was hardcoded string, not variable)
- Fix DATABASE_URL to use template variables directly
- Fix AWS_ACCESS_KEY_ID to match MINIO_ROOT_USER literal
- Remove deprecated: version key, SENTRY_*, NGINX_PORT
- Remove unused env_file from plane-redis
- Add restart policies to all services
* fix(plane): replace MinIO with RustFS (Apache 2.0)
MinIO's open-source edition is effectively dead:
- Admin UI stripped (March 2025)
- Docker images discontinued (October 2025)
- GitHub repo in maintenance mode (December 2025)
- Marked as "NO LONGER MAINTAINED" (February 2026)
RustFS is an S3-compatible drop-in replacement:
- Apache 2.0 license (no AGPL restrictions)
- Same S3 API on port 9000
- Written in Rust, 2.3x faster than MinIO for small objects
- Active development with built-in web console
* fix(plane): address CI and convention issues
- Add back version: "3.8" (required by Dokploy conventions)
- Update meta.json: version v0.27.1 → v1.2.3
- Run process-meta to fix pre-existing strapi duplicate
- Migrator restart: "no" → on-failure
* fix(plane): address review feedback
- Pin RustFS to 1.0.0-alpha.90 (no latest tag)
- WEB_URL and CORS_ALLOWED_ORIGINS use http (Dokploy handles TLS)
* Add Docker Compose configuration for Maxio service
* Add template configuration for maxio service
* Add Maxio logo
* Add Maxio metadata to meta.json
Added metadata for Maxio including links and tags.
* Run node dedupe-and-sort-meta.js
* Fix name from Maxio to MaxIO
* Make suggested updates
* Add missing restart policy
* Make improvements
* feat: add billmora template
* feat: standardize configuration and volume mounts
* feat: hardcode Laravel automations in docker-compose.yml
* fix(billmora): migration race condition
* refactor(billmora): simplify service deploy architecture and standardize blueprint
* feat(billmora): ensure initial data is seeded on startup
* fix(billmora): use storage-based .env persistence to resolve directory mount error
* fix(billmora): revert to separate services for worker and scheduler
* refactor(billmora): remove APP_TIMEZONE from blueprint configuration
* fix(billmora): correct links structure and lowercase tags in meta.json
* fix(billmora): remove invalid volume mounts from template.toml
* fix(billmora): process root meta.json to resolve duplicated templates
* Update Supabase Docker configuration and template
- Updated Supabase Studio and GoTrue images to the latest versions.
- Modified healthcheck commands for the Studio service.
- Enhanced environment variable configuration in docker-compose.yml for better flexibility.
- Updated Logflare API key references and added new S3 protocol access keys in template.toml.
- Introduced custom entrypoint script for Kong to handle Lua expressions and environment variable substitution.
- Added new routes and plugins for enhanced authentication and authorization in Kong configuration.
* Refactor Supabase Docker Compose and Template Configuration
- Removed container name prefixes from services in docker-compose.yml for consistency.
- Increased healthcheck retries and start periods for several services to improve stability.
- Updated healthcheck timeout and retry configurations for the analytics service.
- Adjusted appname generation logic in template.toml to ensure proper naming for services.
- Cleaned up commented sections in template.toml for clarity.
* feat: add rustrak and rustrak-full templates
- rustrak: server-only with SQLite, single service, no external DB
- rustrak-full: server + Next.js dashboard + PostgreSQL
Both use abians7/rustrak-server:v0.2.1, Sentry-compatible error tracking
* chore: update rustrak logo to new design
Introduce Arche, a self-hosted AI workspace platform, with relevant metadata including description, logo, and GitHub link. This addition enhances the diversity of tools available in the project.
Co-authored-by: Mauricio Siu <siumauricio@icloud.com>
