AI-OS (Second-Brain)

chowmes-infra-audit-2026-07-07.md

chowmes server — infra + security audit (2026-07-07)

Live audit of VPS 72.61.72.147 (chowmes), running Arijit's production portfolio.

Box

Ubuntu 24.04.3 LTS · 2 vCPU · 7.8 GB RAM (1.9 used, 5.9 free) · 4 GB swap (0 used) · 96 GB disk (27% used, 71 GB free) · load 0.06 (idle). Huge headroom at rest.

What runs here (single box, whole portfolio)

Scout (docker, /opt/prism/scout) · PRISM + prism-platform/executor/runner/chat-proxy/deploy-hook/ v2-static · Hermes ×3 (hermes, hermes-prism, argus/vulcan profiles) · umami analytics (docker) · ac2-lab-backend (Algolia Central2 lab, docker) · Caddy (reverse proxy + TLS). All app services bound to 127.0.0.1, fronted by Caddy on 443.

Security: STRONG baseline

  • UFW active, default-deny incoming; SSH (22) allow-listed to Arijit's IP only.
  • SSH hardened: pubkey-only, PasswordAuthentication no, PermitRootLogin effectively no (sshd -T).
  • fail2ban active. unattended-upgrades active.
  • All internal ports (8421/8000/3001/9099…) closed to the public (verified externally).
  • TLS 1.3 + HSTS + X-Frame DENY + X-Content-Type nosniff + referrer-policy. Let's Encrypt certs.
  • Port 4719 binds 0.0.0.0 but UFW scopes it to tailscale0 (VPN-only) — safe.

Security: GAPS to close

  1. 10 pending security updates — apply.
  2. Only Scout container has resource limits (1.5cpu/5g). umami, umami-db, ac2-lab-backend, hermes, hermes-prism, caddy all run UNLIMITED → one runaway starves the whole box. Biggest technical concentration risk.
  3. Scout container runs as root (non-root patch deferred).
  4. SSH allow-list pinned to one IP — brittle (Tailscale is the safety net if IP changes).
  5. No central secrets management — per-service .env files.

File layout: functional but MESSY

  • Scout buried at /opt/prism/scout (should be /opt/scout).
  • PRISM appears twice: /opt/prism (558M) AND /opt/PRISM (558M) — likely stale duplicate.
  • 5 prism-* dirs + PRISM + prism + chowmes-prism. Mixed root/chowmesadmin ownership.
  • Not breaking anything (separate dirs/venvs/containers/.env) but no clean per-service convention.

Answers

  1. Concentration risk: single box = single point of failure for the ENTIRE portfolio. Box dies (hardware, OOM, bad deploy, breach, provider) → Scout + PRISM + Hermes×2 + blog + analytics all down at once. Noisy-neighbor (unlimited containers). Shared-fate deploys. Breach blast radius = all services' data. Backups exist (nightly /opt/prism-backup) but recovery = rebuild.
  2. Health/capacity: excellent headroom now; hosts current portfolio + several more light services comfortably. Ceiling = concurrent HEAVY work (~8 parallel browser/CPU bursts) before contention; light API/web services scale to dozens. Secured well; close the 5 gaps above.
  3. Naming + multi-home: "chowmes" reads personal/food, not infra-hub. Multi-homing a new domain is EASY (Caddy fronts by hostname): point new DNS at the box, add Caddy site blocks, run both domains, migrate public URLs at your pace, 301 old→new, retire chowmes whenever. NO big-bang. Caveat: scout.chowmes.com is now the live product URL — decide Scout's public domain BEFORE beta invites (changing it later means updating email/docs/Stripe/API-base + redirects).
  4. Dev/prod split: YES. Move dev to the Hostinger VPS → blast-radius isolation, lean predictable prod, natural staging (test on Hostinger → promote to chowmes).

Roadmap

  • NOW (security, low-risk): apply 10 updates · add resource limits to unlimited containers · verify backups cover ALL services.
  • SOON: pick Scout's product domain before invites · multi-home new domain via Caddy · apply Scout non-root container patch.
  • MEDIUM: reorganize /opt (de-dup PRISM/prism, move Scout to /opt/scout) · stand up Hostinger as dev/staging, move dev workloads.
  • ONGOING: per-service users (not all root/chowmesadmin) · central secrets · monitoring/alerting (disk, mem, service-down).