Built to be rebuilt

Infrastructure you could rebuild from scratch

Everything runs in Europe on rented infrastructure: managed cloud services where a provider does the job best, and rented servers that we manage ourselves. Every server, firewall rule and service is defined in code and version controlled. Nothing is clicked together in a control panel, and nothing lives only in someone's head.

The servers sit behind a load balancer, so adding capacity means starting another one rather than rebuilding anything. Nothing scales on its own: that is a deliberate choice. It keeps a young project cheap to run, and leaves room to grow on the day it is not one.

That claim was tested the hard way. The entire platform was moved between datacenters by destroying every server and rebuilding it from the repository, with a database upgrade folded into the same window. It came back from code and a verified backup.

Releases that undo themselves

A new version is built in its own folder while the current one keeps serving traffic. When it is ready, a single pointer switches over instantly. The new release is then health checked, and if it fails, the pointer flips straight back to the previous version without anyone being called.

Rolling back is not a rebuild. It is the same one second switch, available at any time.

Your data, copied several times an hour

Everything is backed up several times an hour. Exactly how often depends on how recoverable that data is: something the platform could rebuild by itself in the worst case can stand a longer gap than something a person entered once and would never enter again. Everything is encrypted before it leaves the server and stored with a second, independent provider, so a bad day at one company cannot take both the platform and its backups.

Restoring is a single command, and it has been run for real, not just written down.

Watching for silence

Anyone can alert on a server that catches fire. The harder failure is the backup that quietly stops running. Every backup job here has to check in when it starts and when it finishes, and a missed check in raises an alarm on its own.

Alongside that, each server reports its own health, application errors are collected as they happen, and third party packages are scanned continuously for known vulnerabilities and supply chain compromises.

A vulnerability that turns up does not wait to be noticed: security updates are applied automatically. Scanning tells you something is wrong - this fixes it, including on a Sunday morning. That cover is bought rather than assumed: patching runs for the whole set of open-source packages a server actually uses, not only the small core that gets it by default. Nothing quietly falls out of support while it is still running.

Credentials nobody can read by accident

Production credentials are encrypted at rest and never stored in readable form. Infrastructure keys and application keys live in separate places, so neither system can reach the other's secrets. And nothing that touches a credential can print it into a log.

Privacy by design, not in the fine print

The cheapest data to protect is the data you never collected. So the first question in a design here is not how we secure something, it is whether we need to hold it at all. That decision is made early, because early is the only time it is cheap: it shapes what a product is allowed to be - a map of places rather than of people - and it sits in the design rather than in a setting somebody could switch off later.

Where something does have to be recognised, it is done without keeping the person, and for no longer than the job needs. Visitor statistics run on a server we manage ourselves, without cookies, so no third party watches your visitors. All of it sits in Europe.

Client work is held to the same standard, and you can point it at your own site: the GDPR Privacy Check shows what a page really loads, and who it tells about your visitors.