perf(orchestrator): add POSTIZ_ACTIVE_PROVIDERS to limit idle Temporal workers#1651
Conversation
|
Contribution-checker quality warning Heuristics that flagged:
If this is a genuine contribution, please add detail to your PR description and tighten the diff scope before reviewers look at it. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
7620b2a to
3d7ed28
Compare
|
Contribution-checker quality warning Heuristics that flagged:
If this is a genuine contribution, please add detail to your PR description and tighten the diff scope before reviewers look at it. |
…l workers On a default Postiz deployment, getTemporalModule starts one Temporal worker per supported social provider (31 providers + 'main' = 32 workers), regardless of which integrations are actually configured. Each worker long-polls Temporal continuously, causing significant idle CPU/RAM usage even when no posts are scheduled. Root cause (temporal.module.ts): the worker list was built from the full socialIntegrationList with no opt-out mechanism. Fix: introduce an optional POSTIZ_ACTIVE_PROVIDERS env var — a comma- separated list of provider identifiers. When set, only those providers (plus the always-required 'main' worker) start Temporal workers. When unset (the default), all workers start as before — fully backwards-compatible with existing deployments. Example for a deployment using 8 providers: POSTIZ_ACTIVE_PROVIDERS=twitter,instagram,linkedin,bluesky,telegram,facebook,threads,youtube This reduces worker count from 32 to 9, eliminating ~23 idle long-pollers and their associated CPU, RAM, and Postgres connection overhead. Closes gitroomhq#1570
3d7ed28 to
39ab748
Compare
|
Contribution-checker quality warning Heuristics that flagged:
If this is a genuine contribution, please add detail to your PR description and tighten the diff scope before reviewers look at it. |
Problem
On a standard Postiz deployment,
getTemporalModulestarts 32 Temporal workers (one per supported social provider +main), regardless of which integrations are actually configured. Each worker long-polls Temporal continuously, causing significant idle CPU/RAM overhead on every self-hosted instance.From issue #1570, a deployment with only 8 configured integrations reports:
Root cause in
temporal.module.ts:Solution
Introduce an optional
POSTIZ_ACTIVE_PROVIDERSenvironment variable — a comma-separated list of provider identifiers. When set, only those workers (plus the always-requiredmainworker) are started.# Only start workers for the 8 providers you actually use POSTIZ_ACTIVE_PROVIDERS=twitter,instagram,linkedin,bluesky,telegram,facebook,threads,youtubeThis reduces 32 idle workers to 9, eliminating ~23 long-pollers and their CPU/RAM/connection overhead.
Backwards compatibility
When
POSTIZ_ACTIVE_PROVIDERSis unset (the default), all 32 workers start exactly as before. Existing deployments are completely unaffected — no action required on upgrade.Changes
libraries/nestjs-libraries/src/temporal/temporal.module.ts— addsparseActiveProviders()helper and a second.filter()step in the worker list builder.env.example— documents the new variable with all available provider identifiersTesting
POSTIZ_ACTIVE_PROVIDERS→ all 32 workers start (existing behaviour )POSTIZ_ACTIVE_PROVIDERS=twitter,instagram→ 3 workers start:main+twitter+instagramPOSTIZ_ACTIVE_PROVIDERS=TWITTER, Instagram→ case-insensitive + whitespace-trimmed → same 3 workersPOSTIZ_ACTIVE_PROVIDERS=(empty string) → treated as unset, all workers startCloses #1570