Prepared by: swarm manager · Date: 2026-05-22 · Status: plan-only (decision = human, via orchestrator)
Single 4 GB TransIP VPS (136.144.174.219), k3s. Scheduling is on memory requests.
Node allocatable ≈ 3898Mi. With all backends green it sits at ~98% (3820Mi) — and that's with europeLogin already parked (scaled to 0). So a 6th stack (or europeLogin's return) cannot fit without change. Today we can only keep ~4–5 stacks live and must rotate.
| Namespace | backend | datastores | frontend | stack total | |---|---|---|---|---| | recruitment (mahmoud) | 384 | pg 256+128 + redis 64+128 (=576, incl. metrics sidecars) | 64 | 1024 | | claimio | 512 | pg 256 + redis 64 | (none yet) | 832 | | audit-pic | 256 | pg 256 + minio 256 | (none yet) | 768 | | valideerleeftijd | 256 | redis 128 | 64 | 448 | | developer-portal | — | — | nginx 32 (public) | 32 | | athena | 512 | pg TBD (Flyway scaffolded; no Helm subchart yet as of 2026-09-02) | 64 | ~576 | | project subtotal | | | | ~3680Mi |
System pods (kube-system, traefik/svclb, metrics-server, coredns, cert-manager, sealed-secrets, ingress-nginx) ≈ ~700Mi overhead → ~3800Mi total. Little to reclaim there.
These are per-project request right-sizings. No operating-model change, everything stays browser-reachable.
| # | Lever | Saves | Risk |
|---|---|---|---|
| A1 | Disable bitnami metrics-exporter sidecars on mahmoud's pg+redis (metrics.enabled=false) | ~256Mi | None — there is no Prometheus CRD on this cluster (cluster constraint), so the exporters scrape nothing. Pure waste today. Also fix other charts if they enable it. |
| A2 | Right-size claimio backend 512→320Mi + JVM -Xmx256m | ~192Mi | Low — every other backend runs on 256–384Mi; 320 is comfortable. Watch for OOMKilled. |
| A3 | minio request 256→128Mi (auditPic) | ~128Mi | Low — light staging usage. |
| A4 | postgres 256→192Mi ×4 (lower shared_buffers) | ~256Mi | Low — light staging load. |
| A5 | Align redis to 64Mi (valideerleeftijd 128→64) | ~64Mi | None. |
| | Total realistic, safe | ~700–900Mi | |
Impact: ~900Mi reclaimed ≈ a whole stack. Enough to bring europeLogin back AND keep all others (no rotation), or to add real headroom. Recommended floor per layer to avoid OOMKills: Spring backend ≥ 256–320Mi (+matching -Xmx), postgres ≥ 192Mi, redis ≥ 64Mi, minio ≥ 128Mi.
What can move off the VPS to the laptop (docker-compose / k3d/kind)?
| Workload | Local candidate? | Note | |---|---|---| | business / dod scheduled agents | already local (launchd) | Not on the node — no gain. | | developer-portal, WIP frontends | No | Need public ingress + DNS + TLS to be useful; tiny anyway (32–64Mi). | | Per-project datastores | Only for local dev, not staging | Staging datastores must sit next to the staging backend in-cluster; splitting them cross-network is fragile. (Local dev already runs its own docker-compose datastores per the port registry.) | | Whole project stacks | Yes — the real lever | Run the least demo-critical project(s) entirely locally (k3d/kind) for integration/dev, reserving the VPS for the "live/demo" staging stacks. Frees a full ~700–1000Mi per stack offloaded. |
Caveats for local: no public ingress/DNS/TLS (cert-manager can't issue; not browser-reachable externally); local persistence = docker volumes; CLAUDE.md port-registry collisions must be fixed first (europeLogin/claimio both claim redis 6380; mahmoud uses default 5432/6379) before two stacks coexist locally.
Each Option-A trim is a per-project chart change (values-staging) — assignable to the owning worker, capacity-free, no cross-project risk. Awaiting your go-ahead on which levers to apply.
Reacties