Infrastructure architecture
Provider
See Framework → Providers for the actual comparison criteria — ownership structure, values alignment, data jurisdiction, pricing, not just technical feature parity, since most providers offer roughly the same baseline there. This project picked Infomaniak: Swiss, steward-owned, and specifically its Public Cloud (OpenStack) product rather than a plain VPS — see Framework → Public Cloud for why that specific product, not just that provider.
What's provisioned
See Framework → Instance Topology for why a single instance was chosen over a split model.
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.
Disk layout: single volume for future servers
A future server should use a single volume, not this one's boot/data split — boot-from-volume is mandatory regardless, so this just means not adding a second one, with data-root left at its OS-disk default. Saves setup time and keeps things simple: no /mnt/data mount, no data-root/config.toml repointing, no cross-disk confusion about what lives where. A second disk would only pay for itself if the OS needed rebuilding while preserving data in place — but Response to a breach restores each service from its S3 backup instead, so that case never actually comes up.