Cutter 8
- vCPU
- 4 × dedicated
- RAM
- 8 GB
- Storage
- 160 GB NVMe SSD
- Transfer
- 10 TB
- IPv4 / IPv6
- 1 / /64 routed
Solution
Real availability comes from independent failure domains, not from a bigger server. Three instances in three countries with different transit providers survive events that no single machine can. Budget for a load balancer or anycast entry point, synchronous replication within a region, and asynchronous replication across them — latency makes synchronous cross-region writes impractical.
| Resource | What you actually need |
|---|---|
| Nodes | Three minimum, in three jurisdictions |
| Network | WireGuard mesh; anycast available in selected regions |
| Database | Synchronous within region, asynchronous across regions |
| DNS | Short TTLs and health-checked failover records |
Location is usually the decision that matters most for this workload — either because latency dominates, or because jurisdiction does.
Amsterdam, Ashburn and Singapore is the classic triangle.
WireGuard between all nodes, with the application listening only on the mesh.
Synchronous within a region, asynchronous across; know your RPO.
Short TTLs plus a health-checked failover record, or anycast if available.
Kill a region on purpose, on a weekday, while you are watching.
Three is the practical minimum: two gives you a split-brain problem rather than a quorum. Put them in three separate failure domains — different countries, ideally different transit providers.
Only if you route users to their nearest region. Multi-region for availability and multi-region for latency are different designs that happen to share hardware.
Our SLA is 99.99% per instance, which is about 4.4 minutes of downtime a month. Anything beyond that requires redundancy you build yourself.