Same business logic, now hosted on managed AWS primitives instead of a single VPS. The cutover ran 2026-06-08: sales task generation moved off the VPS/n8n onto a Lambda producer/consumer writing a DynamoDB single-table, and the loop generate → review → send is LIVE. The goal was never a rewrite — it was removing the SPOF, centralizing secrets and making queue state observable. The VPS has since been decommissioned too (#152), so the SPOF is gone; the one remaining hardening item is consolidating to a single sender (retiring the legacy n8n send worker).
| Concern | Old (VPS era) | Now (AWS-native) | Status |
|---|---|---|---|
| Generation compute | Single VPS 187.77.29.73 (generate-only) | Lambda producer + consumer · auto-scale | ✅ Done |
| Scheduling | n8n scheduleTrigger × 16 → VPS | Same n8n crons re-pointed to /generate | ✅ Done |
| Auth | URL-embedded Basic | Secrets Manager + IAM | ✅ Done |
| Transport | HTTP plaintext | HTTPS · API GW + ALB | ✅ Done |
| Task store / audit | Airtable task_queue_sales | DynamoDB single-table + Audit_Log | ✅ Done |
| Retries | None · cron just re-fires | SQS + DLQ (maxReceive 5) | ✅ Done |
| Observability | SSH + tail -f | CloudWatch → SNS → #hv-alerts + Sentinel V2 | ✅ Done |
| Send | n8n Gmail cron (Airtable-fed) | message-dispatcher Lambda (SQS outbound) | ⚠️ Live, dual-worker |
| VPS decommission | VPS still up (Deprecated/InCharged crons) | Shut down + leaked credential rotated | ✅ Done (#152) |
The task store moved: the review queue is now DynamoDB, and the human review surface moved from the old Airtable/Netlify queue to Hub v2 /queue. What stayed in Airtable is the config/brain SSOT — the Workflows & Automations kill-switch, Agent Settings, guardrails, suppression and templates. Playbook logic and prompts are unchanged (per ADR 0001) — only the infrastructure and the task store changed.
The cutover did NOT replace the schedulers. The existing n8n cron triggers were simply re-pointed to POST /generate (the producer Lambda behind API GW), which acks in under a second and enqueues to SQS. That kept the schedule definitions where the team already manages them while moving all the compute and retries onto AWS. The two alternatives below were evaluated but not built — kept on the shelf as roadmap.
Move schedules into apps/api alongside Hub v2's existing modules. Auth via Secrets Manager (already wired). Logs/metrics via CloudWatch (already wired).
Pros: retires n8n as the scheduler, git-versioned schedules, one deploy pipeline.
Cons: couples scheduler uptime to Hub v2 API; not needed for the cutover.
EventBridge rules target the producer via SQS, decoupling the schedule from n8n entirely.
Pros: native retry, cross-account ready, no n8n dependency.
Cons: extra surface to monitor, Terraform churn per schedule edit. Keep on the shelf for the day cross-service triggers matter.