GCP migration analysis — near-zero cost alternatives

Decision document. Evaluates leaving GCP entirely to close the gap to $0/mo for Oter + Negodex together. This supersedes the “stay on GCP; no platform migration” stance in gcp-cost-cuts.md — that stance was correct for May 2026 waste-cutting; this doc reopens the question for a different goal (near-zero cost, ops burden accepted).

This is analysis, not a queued migration. Execution would be a separate plan.

Context

The May 2026 cost cuts (see gcp-billing.md) brought monthly GCP spend to ~$22–38 (Scenario A: April total was the whole billing account) or ~$57–67 (Scenario B: Negodex SQL was extra). Cloud SQL now dominates at ~$46–52/mo; every other SKU is effectively at free tier.

The question this doc answers: is it worth leaving GCP entirely for a near-$0 target? Chosen profile:

• Cost target: $0–5/mo (aggressive)
• Ops tolerance: willing to own a VPS
• Scope: Oter + Negodex together (they share oter-db — splitting them recreates the ~$50/mo second-instance problem, so they migrate as one unit)
• Firebase FCM: stays on the existing oter-8c4e4 project regardless — free tier, host-agnostic

Current state (verified 2026-07-07)

Cloud SQL is ~80% of the bill. Every other lever is already pulled.

Recommendation

Move both apps to a single Hetzner ARM VPS (CAX11, ~$4/mo) in Ashburn US-East, running Docker Compose, with Cloudflare R2 for attachments and Cloudflare Access for the internal docs site.

Why this over the alternatives (details in Alternatives considered):

• Only option that plausibly lands under ~$6/mo total for both apps.
• Ashburn keeps LATAM latency in the same region class as today’s us-east1 (delta <20ms).
• Zero reclamation risk (unlike Oracle Always Free).
• Runs on infrastructure we already understand: Docker Compose, Caddy, Postgres.

Target topology

Hetzner CAX11 (Ashburn) — 2 vCPU ARM, 4 GB RAM, 40 GB SSD, 20 TB egress
└── Docker Compose
    ├── caddy         — TLS + reverse proxy (auto Let's Encrypt)
    ├── postgres:18   — one instance, two databases (oter_prod + myecommercedb), volume-mounted
    ├── oter-server   — Ktor container from GHCR
    ├── oter-web      — Next.js container from GHCR
    ├── negodex-api   — Nest container from GHCR
    ├── oter-docs     — nginx serving static docs, behind Cloudflare Access (free)
    └── (optional) uptime-kuma for self-hosted monitoring

Cloudflare R2         — attachments bucket (S3 API, $0 egress, 10 GB free)
Cloudflare Pages      — wasmJS + static docs (already free-tier friendly)
GitHub Container Registry — image storage
Firebase FCM          — unchanged (still push notifications)

Cost projection

That’s a ~78–92% reduction vs current post-optimization spend, and ~95% vs the April 2026 baseline.

Alternatives considered

What actually breaks (change surface)

The migration doc for future-us should enumerate these; not implementation steps, just the surface area.

• Postgres connectivity. oter-db connection string switches from the Cloud SQL socket factory to a standard JDBC URL. server/src/main/kotlin/com/esteban/ruano/utils/Config.kt already handles both — it has a /cloudsql/ socket-factory branch (line ~102) and a standard-JDBC branch. This is essentially an env-var change (DB_HOST / DB_URL). Same for Negodex Nest API.
• Attachments. server/src/main/kotlin/com/esteban/ruano/service/GcsFileStorageService.kt becomes an S3-client implementation pointed at R2. R2 exposes an S3-compatible API, so software.amazon.awssdk:s3 with a custom endpoint works. Lifecycle rules (STANDARD → NEARLINE → COLDLINE) become R2 lifecycle rules (fewer tiers; at single-digit GB the difference is <$1/mo).
• Secrets. Secret Manager mounts (--set-secrets in publish-server-release.yml) become .env files on the VM, owned by root, read by docker compose. Rotate via SSH + docker compose up -d. Trade-off: no audit trail, no per-service scoping.
• CI/CD. GitHub Actions currently uses WIF → gcloud run deploy. New flow: build container → push to GHCR → SSH to the VM → docker compose pull && docker compose up -d. Requires an SSH deploy key stored as a repo secret. Three workflows to rewrite: publish-server-release.yml, publish-web-release.yml, publish-docs-release.yml.
• Internal docs auth. Cloud IAP → Cloudflare Access (free tier: up to 50 users, Google/GitHub SSO). Nearly at-parity feature-wise.
• Firebase / FCM. No code change; NotificationService.kt already reads credentials from a file path. Credentials JSON just moves from Secret Manager to a mounted file.
• Backups. Cloud SQL’s 7-day retained backups + 7-day PITR become pg_dumpall cron → R2 (encrypted). Hetzner snapshots (~$0.40/mo) cover the VM. No PITR. Accept RPO of ~24h. A restore drill should be documented and run once before cutover.
• Observability. Cloud Logging → docker compose logs + optional Loki Cloud free tier (already wired in logback.xml). Uptime monitoring via Uptime Kuma on the same VM or Better Stack free tier.
• DNS + TLS. Move DNS to Cloudflare (or keep current), point A records at the VM, Caddy handles Let’s Encrypt automatically.
• Dependency cleanup. server/build.gradle.kts can drop com.google.cloud.sql:postgres-socket-factory and com.google.cloud:google-cloud-storage. Keep firebase-admin.

Risk register

Trigger conditions for revisiting

Migrate now if:

• Current spend consistently exceeds ~$30/mo (Scenario B is live) and no further GCP-side cut is available.
• We’re comfortable owning weekly ops for both apps.

Defer migration if:

• Scenario A is confirmed by billing export and monthly spend stays under ~$25.
• Traffic grows enough that a $4 VPS won’t fit — at that point the analysis changes (managed Postgres becomes worth its price).
• We plan to add more apps to the shared Cloud SQL instance (amortizes the fixed cost further and pushes the crossover further out).

Revisit within a year regardless if:

• Hetzner raises prices >20%.
• Oracle Always Free ARM reclamation policy changes materially (would make it a genuine alternative).
• We stop needing Negodex — the shared-SQL argument collapses and Neon Launch ($19) becomes the obvious answer for Oter alone.

Related

• gcp-billing.md — baseline, cuts applied, forecast
• gcp-cost-cuts.md — May 2026 runbook (stay-on-GCP stance; superseded by this doc for the near-zero goal)
• hetzner-migration-runbook.md — the follow-up runbook that executed this analysis

← Infrastructure docs · ← Docs index