Same business logic, hosted on managed AWS primitives instead of a single VPS. The goal isn’t a rewrite — it’s removing the SPOF, centralizing secrets and making schedule + queue state observable.
| Concern | Today | Target (F5) | Phase |
|---|---|---|---|
| Compute | Single VPS 187.77.29.73 | ECS Fargate · multi-AZ | F3 |
| Scheduling | n8n scheduleTrigger × 16 | EventBridge rules | F4 |
| Auth | URL-embedded Basic | Secrets Manager + IAM | F2 |
| Transport | HTTP plaintext | HTTPS + ALB | F3 |
| State / audit | Airtable only | RDS Postgres + Airtable | F3 |
| Retries | None · cron just re-fires | SQS + DLQ | F4 |
| Observability | SSH + tail -f | CloudWatch + OTel | F2 |
| Secret rotation | Edit 16 workflows | Managed rotation policy | F2 |
Airtable remains the SSOT for approval state, bot definitions and guardrails. The migration is infrastructure-only — playbook logic, prompts and the human review surface don’t change.
Two viable paths to retire the 16 n8n cron triggers. The diagram above shows EventBridge for symmetry with the rest of AWS, but the team is converging on Hub v2's NestJS scheduler because that infra already exists.
Schedules live in apps/api alongside Hub v2's existing modules. Auth via Secrets Manager (already wired). Logs/metrics via CloudWatch + OTel (already wired).
Pros: zero new infra, git-versioned schedules, one deploy pipeline.
Cons: couples scheduler uptime to Hub v2 API.
Effort: 1 day per batch of 5 callers. See Hub v2 → n8n migration.
16 EventBridge rules target the Fargate worker via SQS. Decouples scheduler from API.
Pros: survives Hub v2 outages, native retry, cross-account ready.
Cons: extra surface to monitor, Terraform churn per schedule edit.
Effort: 2-3 days plus IaC. Keep on the shelf for the day cross-service triggers matter.