Architectures
Possible Architectures
Single-VM Model
The current server is manually provisioned — set up by hand, not from code. Moving straight to the split maintenance + services-1 model in one step would mean adopting Terraform and re-architecting the setup at the same time. Instead, the first migration step is a single Terraform-managed VM, sized to match what's already running, so each change can be tested on its own.
personal-services
| Resource | Spec |
|---|---|
| Flavour | a4-ram16-disk0 (4 vCPU, 16 GB RAM, no bundled disk — boot-from-volume only) |
| Boot volume | 20 GB, CEPH_1_perf1 — disposable OS install |
| Data volume | 80 GB, CEPH_1_perf1 — mounted at /mnt/data, where Docker's data-root points |
| Network | Single NIC, direct-attached to ext-net1 (shared, dual-stack) — public IPv4 + IPv6 on one port, no router or floating IP |
| Security group | SSH (22), HTTP (80), HTTPS (443) — each rule duplicated per ethertype (IPv4 + IPv6) |
No router, private network, or floating IP — those exist to decouple a public IP from an instance's lifecycle and to give multiple instances a private backend, neither of which matters yet for one box. That's what the split model reintroduces once there's more than one instance to isolate and interconnect.
Split Model
The target end state: dedicated instances per role instead of one VM running everything. See Public Cloud for the reasoning — blast-radius containment, right-sized resources per workload, and Coolify's team model wanting separate compute per team.
| Instance | Role | Flavour | Block volume |
|---|---|---|---|
maintenance | Coolify + monitoring | a2-ram4-disk0 (2 vCPU, 4 GB RAM) | 30 GB, Perf1 |
services-1 | User-facing services | a4-ram8-disk0 (4 vCPU, 8 GB RAM) | 60 GB, Perf1 |
Both would share the same private network, router, and security group as the single-VM model.
Conclusion
Single-VM, for now. The deciding factor is compute peaks: workloads on this box are bursty and uneven, not steady, so a fixed per-instance split works against us. services-1 capped at its own 4 vCPU/8 GB would hit a hard ceiling during a spike even while maintenance sits mostly idle right next to it. A single VM pools the full 4 vCPU/16 GB across every container instead, so a peak anywhere can draw on capacity that's idle elsewhere rather than stalling at a per-instance limit.
That headroom matters more right now than the isolation the split model buys. Revisit once there's an actual reason blast-radius containment outweighs pooled capacity — more services, less predictable load, or a real need to separate maintenance from what it's monitoring.