fix(postiz): Resolve Temporal crash loop by isolating Workflow database#800
fix(postiz): Resolve Temporal crash loop by isolating Workflow database#800chahat1709 wants to merge 2 commits intoDokploy:canaryfrom
Conversation
built with Refined Cloudflare Pages Action⚡ Cloudflare Pages Deployment
|
There was a problem hiding this comment.
Pull request overview
This PR aims to stop Postiz’s Temporal component from crash-looping by isolating Temporal onto its own Postgres instance, and it introduces a Temporal Web UI service for workflow monitoring.
Changes:
- Added dedicated Temporal services (
temporalio/auto-setup,temporalio/ui) plus a separate Postgres instance for Temporal persistence. - Wired Postiz to Temporal via new environment variables and added
depends_onhealth-based startup ordering. - Added a new persistent volume for Temporal’s database.
| healthcheck: | ||
| test: ["CMD", "tctl", "--address", "localhost:7233", "cluster", "health"] | ||
| interval: 10s | ||
| timeout: 5s | ||
| retries: 10 | ||
| start_period: 30s |
There was a problem hiding this comment.
postiz-app depends on postiz-temporal being service_healthy, but the Temporal healthcheck runs tctl inside the temporalio/auto-setup container. This is relatively brittle (CLI availability/behavior changes) and differs from existing patterns in the repo (e.g. blueprints/peerdb/docker-compose.yml uses a dedicated temporalio/admin-tools container for tctl). Consider switching to a simpler healthcheck (port/grpc probe) or adding an admin-tools container for CLI-based checks so postiz-app startup doesn't get blocked by a failing healthcheck.
| restart: always | ||
| environment: | ||
| - TEMPORAL_ADDRESS=postiz-temporal:7233 | ||
| - TEMPORAL_CORS_ORIGINS=http://localhost:8080 |
There was a problem hiding this comment.
postiz-temporal-ui sets TEMPORAL_CORS_ORIGINS to http://localhost:8080, which won’t match the actual origin when deployed behind Dokploy (and may break UI/API calls due to CORS). Make this configurable (e.g., derived from ${POSTIZ_HOST} / ${domain}) or relax/remove it if not required for this setup.
| - TEMPORAL_CORS_ORIGINS=http://localhost:8080 | |
| - TEMPORAL_CORS_ORIGINS=https://${POSTIZ_HOST} |
| postiz-temporal-ui: | ||
| image: temporalio/ui:2.30.0 | ||
| restart: always | ||
| environment: | ||
| - TEMPORAL_ADDRESS=postiz-temporal:7233 | ||
| - TEMPORAL_CORS_ORIGINS=http://localhost:8080 |
There was a problem hiding this comment.
PR description says Temporal Web UI is added for monitoring, but this compose change doesn’t include any Dokploy domain/proxy configuration for postiz-temporal-ui (e.g., no corresponding [[config.domains]] entry in template.toml). As-is, the UI container will run but won’t be reachable via Dokploy without an exposed domain/port mapping.
| - POSTGRES_USER=${DB_USER} | ||
| - POSTGRES_PWD=${DB_PASSWORD} | ||
| - POSTGRES_SEEDS=postiz-temporal-postgres | ||
| - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml |
There was a problem hiding this comment.
postiz-temporal is using DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml, which is a dev-oriented dynamic config. For a deployment blueprint, this should typically use the production SQL dynamic config (consistent with e.g. blueprints/peerdb/docker-compose.yml using production-sql.yaml) to avoid enabling dev defaults in production.
| - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml | |
| - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/production-sql.yaml |
| postiz-temporal-postgres: | ||
| condition: service_healthy | ||
| healthcheck: | ||
| test: ["CMD", "tctl", "--address", "localhost:7233", "cluster", "health"] |
There was a problem hiding this comment.
tctl not present in auto-setup image — healthcheck always fails
tctl is only bundled in the temporalio/admin-tools image, not in temporalio/auto-setup. The official Temporal docs state: "Together with the tctl CLI, these binaries are available in the temporalio/admin-tools Docker image." Running CMD tctl inside the postiz-temporal container will exit with "executable file not found", so the container is never marked healthy, and postiz-app (which requires condition: service_healthy) will never start — defeating the purpose of this fix.
A TCP-reachability check is the most portable alternative since you can't rely on any specific CLI being present in the auto-setup image:
| test: ["CMD", "tctl", "--address", "localhost:7233", "cluster", "health"] | |
| test: ["CMD-SHELL", "nc -z localhost 7233 || exit 1"] |
If nc is also unavailable, a pure-shell approach works: ["CMD-SHELL", "(echo > /dev/tcp/localhost/7233) 2>/dev/null || exit 1"].
| condition: service_healthy | ||
|
|
||
| postiz-temporal: | ||
| image: temporalio/auto-setup:1.27.2 |
There was a problem hiding this comment.
temporalio/auto-setup is deprecated
Docker Hub marks this image as: "temporalio/server paired with temporalio/admin-tools for schema setup, as shown in the official samples. This is fine for a quick fix, but worth tracking for a follow-up migration.
Resolves an issue where the Temporal auto-setup script fails to start due to schema contention with the main Postiz backend. This adds a dedicated Temporal Postgres service and the Temporal Web UI for workflow monitoring.
Greptile Summary
This PR correctly isolates Temporal's schema into its own dedicated PostgreSQL instance (
postiz-temporal-postgres) to fix the schema contention crash loop, and adds the Temporal Web UI for monitoring. However, the healthcheck onpostiz-temporalusestctl, which is only available in thetemporalio/admin-toolsimage — not intemporalio/auto-setup. The container will never report healthy, andpostiz-app(which depends oncondition: service_healthy) will never start.tctlis absent fromtemporalio/auto-setup:1.27.2; replace the healthcheck with a TCP probe (nc -z localhost 7233) so the dependency chain can resolve.temporalio/auto-setupis officially deprecated on Docker Hub; a follow-up migration totemporalio/server+temporalio/admin-toolsis recommended.Confidence Score: 4/5
Not safe to merge as-is — the broken healthcheck prevents postiz-app from ever starting.
The architectural fix (dedicated Temporal Postgres) is correct, but the P1 healthcheck bug using a non-existent binary (tctl) in the auto-setup container will block postiz-app from starting entirely. One targeted fix to the healthcheck command is needed before this is mergeable.
blueprints/postiz/docker-compose.yml — specifically the healthcheck.test on the postiz-temporal service (line 46).
Reviews (1): Last reviewed commit: "fix(postiz): Resolve Temporal crash loop..." | Re-trigger Greptile