The brain runs on Google Cloud
here is exactly how it works, what it costs, and how it stays safe

Google Cloud hosts a single virtual machine called iexdg-nexus-vm. That VM runs four daemons that together expose two public surfaces: a static dashboard at the root of brain.iexdg.com, and the MCP endpoint that Claude Desktop talks to. Everything else (Notion, GoHighLevel, RAG, Culture Pulse data) lives behind the VM and is reached over outbound HTTPS to those upstream APIs.

The four daemons on the VM

External surfaces

Hardware and image

Filesystem layout

Process tree (post-Apr 27)

systemd
├── caddy.service                 (root → caddy user)
├── iexdg-api.service              (iexdg user, FastAPI :8000)
├── iexdg-mcp.service              (iexdg user, FastMCP bearer :8765)
├── iexdg-mcp-oauth.service        (iexdg user, FastMCP OAuth :8766)
├── iexdg-health-check.timer       → iexdg-health-check.service (every 5 min)
├── iexdg-ghl-observer.timer       → iexdg-ghl-observer.service (every 15 min)
└── iexdg-content-drop.timer       → daily_content_drop.py (2 AM CST)

All four primary services run as the unprivileged iexdg user. None can escalate to root, none can access each other's home directory, none can read /etc/default/iexdg-mcp outside of the systemd-injected env. Service hardening details are documented inside each .service file.

Pre-stage state (Apr 27 03:30 UTC)

• Wrapper · iexdg_mcp_oauth_wrapper.py uploaded to /opt/iexdg-mcp/
• Systemd unit · iexdg-mcp-oauth.service registered with systemd, currently disabled (will not start until Google credentials are present)
• Token storage · /var/lib/iexdg-brain/ created, mode 700, owned by iexdg user
• Caddyfile.oauth.staged · new Caddyfile with the seven OAuth metadata routes uploaded to /etc/caddy/Caddyfile.oauth.staged · not yet active
• Caddyfile.bak-pre-oauth-apr27 · current live Caddyfile backed up before any swap
• fastmcp v3.2.4 · installed in /opt/iexdg-mcp/venv alongside authlib, httpx, itsdangerous
• 33-tool lift verified · the wrapper's pattern of importing the legacy mcp instance and re-registering its 33 tools on a new fastmcp v3 instance was probed and works (ToolManager.\_tools dict size = 33)
• GHSA-5h2m-4q8j-pqpj patch confirmed · the resource parameter audience check is present in fastmcp 3.2.4 source
• Live brain unaffected · all three legacy services (mcp, caddy, api) still active, /api/health returns 200

What is needed to ship live

1. Robert · Google Cloud Console · 10 minutes · Add a new OAuth client of type Web application to the existing drdnicole-youtube-manager project (Phase 1 of the OAuth runbook). Re-using the existing project saves 20 minutes and keeps audit logs in one place. Authorized redirect URI: https://brain.iexdg.com/auth/callback. Grab the Client ID and Client Secret from the credentials modal.
2. Robert pastes credentials to Claude · 30 seconds · Robert sends the Client ID and Secret in a secure channel
3. Claude finishes deploy via SSH · 5 minutes · Append credentials to /etc/default/iexdg-mcp, swap Caddyfile, start iexdg-mcp-oauth.service, reload Caddy, run smoke tests against the seven OAuth metadata endpoints
4. Robert end-to-end test · 5 minutes · From Robert's own Claude Desktop, add custom connector at https://brain.iexdg.com/mcp, complete Google sign-in, verify 33 tools appear
5. DNicole switchover · 2 minutes · Same UI flow on her Mac, signed in as drdnicole@iexdg.com
6. T+7 days · sunset bearer for human users · The legacy /mcp-bearer route stays for cron during the migration week, then we remove it (or keep it gated for cron-only)

OAuth clients in IEXDG GCP

Re-using the same GCP project for both clients keeps the audit trail in one place. Each client has its own Client ID and Secret, isolated.

What is backed up today

Recommended snapshot policy (next sprint)

gcloud compute resource-policies create snapshot-schedule iexdg-weekly \
    --description "Weekly snapshot of iexdg-nexus-vm" \
    --max-retention-days=30 \
    --start-time=05:00 \
    --weekly-schedule=Sunday \
    --on-source-disk-delete=keep-auto-snapshots \
    --region=us-east4

gcloud compute disks add-resource-policies iexdg-nexus-vm \
    --resource-policies=iexdg-weekly \
    --zone=us-east4-b

Cost: ~$0.026/GB/month for snapshot storage. 10 GB disk × 4 weeks retention = $1/mo. Negligible.

Recovery procedure if the VM dies

1. Identify latest snapshot: gcloud compute snapshots list --filter='sourceDisk:iexdg-nexus-vm'
2. Create disk from snapshot: gcloud compute disks create iexdg-nexus-vm-restored --source-snapshot=<snapshot-name> --zone=us-east4-b
3. Boot a new VM with that disk attached
4. Re-attach the static IP to the new VM
5. Verify Caddy auto-renews TLS, services come up, /api/health returns 200
6. Estimated total time · 30 minutes if Robert is at the keyboard

Health worker (every 5 minutes)

The iexdg-health-check.timer fires every 5 minutes and runs workers/health_check.py with 7 checks:

1. caddy responsive on :80
2. iexdg-mcp.service active
3. iexdg-api.service active
4. /api/health returns 200 within 10 seconds
5. Disk usage below 85%
6. Memory available above 200 MB
7. TLS cert expires more than 7 days from now

Any failure triggers systemctl restart on the affected service via a sudoers drop-in. If restart fails twice in 15 minutes, the worker writes a notice to /var/log/iexdg-mcp/health.alerts.

Public health endpoint

Anyone can hit https://brain.iexdg.com/api/health with no auth and get a JSON response showing all four services' liveness. This is what the dashboard reads, what the health worker reads, and what an external uptime monitor (Robert's UptimeRobot, future) reads.

{"ok":true,"service":"iexdg-api","ts":"2026-04-27T07:29:18Z","notion_configured":true,"version":"0.1.0"}

Future · alerts to Slack and email

When the May sprint adds Cloud Monitoring, the health-alerts log will be tail-piped to Cloud Pub/Sub which fans out to a Slack webhook and an email to dovewebconsulting@gmail.com. RPO 5 minutes for any service crash. Cost: $0 within Cloud Monitoring's free tier.