perf: cut Postiz memory footprint for single-tenant use (v0.3.0)

[fatherlinux]

Summary

The container was pinned against its 2g cgroup limit with 1GB in swap — it had hit memory.max 133,238 times and been OOM-killed once. A restart reclaimed nothing: it returned to 2015M with 841M swapped within four minutes, which rules out a leak. This is a container sized for a workload it does not have.

Actual scale: 1 user, 6 integrations, 461 lifetime posts.

Root cause

temporal.module.ts registers one Temporal worker per supported provider rather than per connected one — 31 workers. Each carries its own @temporalio/core-bridge Rust core and thread pair, allocated outside the V8 heap where --max-old-space-size cannot bound it.

Confirmed by thread accounting in the running orchestrator:

threads	name
31	workflow-proces
31	temporal-real-s
12	tokio-runtime-w
37	node
4	libuv-worker

117 total — exactly one workflow-proces/temporal-real-s pair per worker, against 1,088,416 kB of private dirty anonymous memory with the heap capped at 432MB.

Changes

1. POSTIZ_ACTIVE_PROVIDERS (in fatherlinux/postiz-app@crunchtools-patches) trims workers 31 → 7. Unset preserves upstream behaviour exactly. Also pins maxCachedWorkflows instead of inheriting the SDK default, which derives from heap_size_limit and lands near 135 per worker.
2. ecosystem.config.js runs node directly instead of pnpm → dotenv → node, dropping six wrapper processes (~195MB). The dotenv layer reads /app/.env, which this image never creates.
3. Per-app heap caps via PM2 interpreter_args, plus Temporal/postgres pools sized for one tenant.

Test plan

• ecosystem.config.js parses; all three apps resolve to direct node invocations with distinct heap flags
• Worker filter logic exercised against the real 32-provider list: unset → 31 workers (upstream preserved), 6 configured → 7 workers, main always present, typos and stray whitespace handled
• Verified nestjs-temporal-core forwards workerOptions into Worker.create via Object.assign (temporal-worker.service.js:182-186)
• Verified a CLI heap flag overrides inherited NODE_OPTIONS (128 → 176MB ceiling vs 432MB from env)
• GHA build + container test
• Post-deploy memory measurement on lotor

Caveat

A provider absent from POSTIZ_ACTIVE_PROVIDERS has nobody polling its task queue, so its posts enqueue and never execute. The boot log prints the active set and warns on unknown identifiers. Add the identifier and restart when connecting a new provider.

Note: postiz-pg-init.sh only runs on first init, so its new values do not affect the existing volume — that postgresql.conf is edited separately.