Home / Reference architectures
REF/ — Reference architectures
Designs we build from.
Starting points rather than templates. Each one is a shape we have implemented and operated, with the reasoning attached — including where it stops being the right answer.
ARC/01 — Network
Segmented small-office network.
Four segments and a default-deny policy between them. The design principle is that the weakest device on a network should not be able to set the security level of the whole business, which is exactly what a single flat subnet arranges.
Why it's shaped this way
- Guest never touches internal. Cheapest meaningful win available
- IoT and CCTV are quarantined — unpatchable devices with no reason to initiate anything
- Servers accept, never initiate. A compromised server shouldn't be able to scan the office
- Monitoring spans everything, configured during the build rather than as a later phase
Where it stops fitting
- Multiple floors or sites need routed distribution rather than one core switch
- Legacy broadcast-dependent software may force compromises — establish this before the cutover
- Above roughly 100 users, per-user policy starts to beat per-segment policy
ARC/02 — Delivery
Push-based deploy across a network boundary.
The conventional pipeline has the server pull from the repository. That requires the repository to be reachable from the server — which, if your source of truth lives on a private network, means exposing it. Inverting the direction removes the requirement entirely.
Why it's shaped this way
- Nothing inbound is required. The private side initiates; compromising the public server yields no path back
- The scan is a gate, not an annotation — it sits before deploy, so a critical finding stops the release
- Notifications fire on failure only. Silence means success, so a message always warrants attention
- Deploys never overwrite environment configuration, so secrets stay out of the repository
Where it stops fitting
- Many target hosts — push does not fan out gracefully; that is where pull-based GitOps earns its keep
- Cross-architecture builds need care about where images are built versus scanned
- Zero-downtime requirements need a rolling strategy in front of this, not a restart
ARC/03 — Resilience
3-2-1 backup with an immutable copy.
Three copies, two media, one off-site — plus the modern addition that decides whether you recover from ransomware: at least one copy that cannot be altered or deleted, even by someone holding valid credentials.
Why it's shaped this way
- Local copy for speed. Restoring 800 GB from cloud storage over an office line is a two-day outage
- Immutable copy for the bad case — object lock costs almost nothing and is the difference between recovery and negotiation
- Backup credentials separated from domain accounts, so one compromise doesn't reach both
- Restore testing scheduled, because untested backups fail silently and always have
Where it stops fitting
- Very low RPO requirements need continuous replication, not scheduled jobs
- Databases need consistent snapshots — copying an open file produces something that will not restore
- Data residency rules may constrain where the off-site copy can physically live
CTA/ — Your environment
Want one of these adapted to your setup?
These are starting points. The useful version is the one that accounts for your building, your budget, and the legacy system nobody wants to talk about.
Start a conversation →