DevOps Server Request #2 — AHU AI Platform (backup target + LB/WAF)
Scope: the two hosts from the original request (2026-07-06-devops-server-request.md) that were called out there as needed but weren't part of the 6 delivered. Nothing new architecturally — this is a follow-up on the original ask, not a new design.
Why now: the backup target has come up as the single most-repeated open item across three separate audits since the 6 hosts landed — there is currently no recovery story at all for the governance/audit database. The LB/WAF gap got re-confirmed this week too: the box that was temporarily standing in for it turned out to be Efran's own private server, borrowed short-term for the project — not something production can depend on, so this is a real gap again, not a config change away from solved.
Every host, regardless of tier
Same baseline as the original request — no changes:
- OS: Ubuntu 22.04 or 24.04 LTS
- Time sync: NTP/chrony — mandatory
- Access: SSH key-only (no passwords), reachable only via bastion/VPN — no direct SSH from the internet on any host, including the LB
- Runtime: Docker + Docker Compose v2
- Firewall: default-deny, explicit allow rules only (matrix below)
- Monitoring: disk-usage alerting at 70% (warning) / 85% (critical)
- Patching: monthly patch window (not fully unattended)
- Network: its own private VLAN/subnet where practical
Requested hosts
| Host | Zone / role | vCPU | RAM | Disk | Network |
|---|---|---|---|---|---|
ahu-backup-01 |
Backup target: object storage / PITR service for the governance host's TimescaleDB (audit-integrity store) and the internal-engines Postgres/pgvector instances | 4–8 | 8–16 GB | multi-TB, expandable (start ~2 TB — sized by retention policy, which isn't finalized yet; growable is the important property, not the starting number) | Internal-only, no path from DMZ or the internet, same isolation posture as the DWH zone |
ahu-lb-01 (only if the on-prem route is chosen — see note) |
Public LB + WAF, fronts ahu-dmz-01 only |
4–8 | 8–16 GB | 50–100 GB SSD | Public-facing — the only host in the whole platform with an internet-facing port |
Note on the LB/WAF row: the original request said "managed cloud LB/WAF preferred; one small dedicated host if on-prem-only" — that preference still stands. This row is here so the on-prem fallback is spec'd if a managed service isn't the direction devops wants to go; if a managed LB/WAF gets picked instead, this row simply isn't needed and can be dropped from the order.
Why the backup target isn't sized like the DWH storage host: the original request's ahu-dwh-store-01 (8–16 vCPU / 32–64 GB / multi-TB) is a different, heavier role — it's meant to serve as an active lakehouse's operational storage layer once that engine exists. A backup target is mostly I/O- and capacity-bound, not compute-bound — it receives WAL/PITR streams and periodic dumps, it doesn't serve interactive queries. Lighter compute, same "needs room to grow" disk story.
Firewall / allowed-path additions (append to the existing matrix)
| From | To | Port/service | Notes |
|---|---|---|---|
| Internet | ahu-lb-01 |
443 | Only public entry point in the whole platform, if the on-prem LB route is chosen |
ahu-lb-01 |
ahu-dmz-01 |
app port | |
ahu-gov-01 (TimescaleDB) |
ahu-backup-01 |
PITR/WAL-streaming port | Outbound push from governance; not a pull — the backup target never reaches into governance |
ahu-int-01 (Postgres/pgvector) |
ahu-backup-01 |
backup-tool port (pg_dump/object-storage API) |
Same push-only direction |
| Admin/VPN | ahu-backup-01 / ahu-lb-01 |
SSH | Via bastion only, same as every other host |
| DMZ / Internet | ahu-backup-01 |
— | Explicitly denied — the backup target holds the same audit/PII data as governance, one hop removed; it gets the DWH zone's isolation posture, not a lighter one |
| Everything else | — | — | Denied by default |
Explicitly out of scope for this request
- DWH hosts — already delivered (
ahu-dwh-01,ahu-dwh-store-01), sitting idle until that engine is built. Not touched here. - HA-tier duplicates (2nd control-plane host, DMZ pair, DB standby, etc.) — those come with the HA tier from the original topology doc, once the current single-instance MVP is live and stable. Not requested yet.
- A dedicated CI runner — came up as a possible future need if/when deploys move from human-triggered to automated (needs a runner living inside the VPN, since GitHub-hosted runners can't reach this network at all). Not urgent, not requested here — flagging only so it doesn't come as a surprise later.