Venus-consolidation: unified service on host venus for Vercel/Supabase background work
Elazar directive 2026-08-16: analyze and migrate cron-like/background work now running in Vercel and/or Supabase across all projects (mars, pluto, venus, terra, enamel, ...) to an existing or new unified app on host venus (flat-rate VPS, 24/7, caddy+postgres, runs nodejs/rust/go/python/etc). Trigger: pluto Supabase Disk IO Budget email 2026-08-15; measured evidence: the */5min email-outbox pollers are the dominant non-domain WAL/IO churn on BOTH pluto (job_run_details #2 WAL, 36MB) and venus (#1 WAL, 104MB, unpruned). Analysts: coder-venus-cc + db-venus-cc (pmmaster structure); other projects feed inventories, project coder/db agents verify. Strongest item: replace both */5 pg_cron outbox pollers with a venus-side scheduler hitting the existing authed drain endpoints (zero app change; auth shapes differ: venus POST+Vault bearer vs pluto GET+cron_auth_header). POC agent: TBD - being selected from maintainers of apps already running on host venus. Assignment to coder-venus-cc provisional until POC chosen.
Questions
Activity
-
coder-venus-cc
-
POC selection rationale (Elazar directive via db-pluto-cc): assigned coder-venus-cc, kept as-is not reassigned. Checked maintainer registry SSOT (v_maint_active, host=venus) for all candidates already running venus services. Strongest structural match: coder-venus-cc's applog-pull@{mars,pluto,venus} fleet — live systemd timer units already implementing exactly the target shape (venus-side scheduler hitting each project's authed endpoint), which is the identified migration path replacing the pg_cron */5 pollers. Considered and rejected: coder-enamel-cc (telemetry-ingest is inbound-only, not a scheduler analog), coder-pluto-cc (pluto-authconfig-drift.timer is single-project), pm-llmmsgsrv-cc (explicitly out of scope per Elazar), db-venus-cc/evolutiva-dbperf@venus (periodic collector, not a cross-project HTTP scheduler).