Infrastructure and security

Machines that rebuild identically

Every server is born from versioned recipes, not from a lucky terminal session. Procedures live in the repository next to the code they govern, and every structural choice leaves its reasoning on record.

Destructive operations have declared, repeatable behaviour: re-running must do no harm, and that has to be tested rather than hoped for.

The boundary is the network, not good faith

Separating customers at the network layer costs more effort than filtering them in code, but it is the only layer that holds when the code is wrong: dedicated networks per customer and ingress through a tunnel instead of ports open to the internet.

Credentials live in a vault with short-lived certificates: the application receives keys generated on the spot, not strings copied into a config file.

Noticing before the customer does

Metrics, checks that tell "powered on" from "working", alerts that fire on useful symptoms instead of every flicker. An alarm that always rings is an alarm switched off.

Where it makes sense the reaction is automatic and graded: the light remedy first, then the heavy one, and if the problem repeats it stops insisting and calls a person. Every attempt stays on the record.

Backups we can restore, evidence that holds

An unverified backup is just a file. The restore drill must be automated onto a throwaway database and must also check that the protections really come back — not that they exist, that they work.

Recovery objectives (how much time, how much data) are declared per service and measured with periodic drills: a number never verified is a wish, a number that came out of a drill is a commitment.

The same things that keep the system up produce the evidence for an audit: append-only event log, incident history, periodic report. If producing evidence needs a person exporting by hand, that evidence will arrive late.

Where we put the machines, and why

There is no universally right answer, which is why we don't sell a single platform. The predictable load of a system used by forty people has no need for public cloud elasticity, and pays for it every month anyway. An online shop with seasonal peaks genuinely benefits from it.

The setup we most often see working is mixed: email and collaboration on managed services, business system and data on controlled machines, backups in a third place that doesn't depend on the first two. What matters is that each piece is a deliberate choice and not an inheritance.

And that it is written down why it sits there: most infrastructure we find wasn't designed, it accumulated.

Updating without stopping

Unpatched systems are the most common entry point after stolen credentials. But updating is frightening because something breaks every time — and fear, after a while, produces machines frozen three years back.

The way through is making it boring: test environments identical to production, coordinated updates in a declared window, one machine at a time with a check after each, and the ability to roll back in minutes. When going back is easy, updating stops being a gamble.

What we hand over besides the machines

An inventory of what exists and what it is for. Operating procedures for the things that happen: a full disk, a service that won't restart, a restore. The incident response plan with names and numbers, not generic roles.

And the credentials, in a vault that is yours. It is the point we insist on most: infrastructure you don't hold the keys to is not yours, however well it is built.