What this covers
Infrastructure is everything between the code you wrote and the person using it: the server, the container it runs in, the proxy that terminates TLS, the deployment that puts a new version live, the backup that exists when something goes wrong, and the monitoring that tells you before a customer does. We design, build and run that layer, either for a new product or as a rescue for something that has grown without a plan.
It is deliberately a boring service. The goal is not to use the most interesting technology; it is to make the system predictable, repairable and cheap enough to keep.
Containers and reproducible environments
We package applications as Docker containers so that the thing tested on a laptop is the thing that runs in production. Staging and production use the same images with different configuration, which removes the classic “it works on my machine” gap. State lives outside the container — in a mounted volume or a managed database — so containers can be replaced instead of nursed.
Images are built from small bases, run as unprivileged users where the software allows it, and are pinned to versions that do not move under you. Rebuilding a month later produces the same result, which matters more than most teams expect until the first emergency.
Deployments you can undo
A deploy should be a small, repeatable event. We use scripts rather than a sequence of remembered commands: sync the files, tag the current image, start the new one, check it answers, and keep the previous version ready to restore. If a check fails, the change is reverted before it is allowed to sit in production.
Because the previous image is kept and tagged, rollback is a single command rather than an archaeology exercise. We write that command down and test it, because an untested rollback is only a hope.
TLS, proxies and hardened defaults
Every site we run sits behind a reverse proxy that handles TLS certificates and renewal, redirects HTTP and the secondary hostname to the canonical address, and adds security headers at the edge: HSTS, a content security policy, frame denial, MIME sniffing protection and a strict referrer policy. Administrative interfaces are bound to loopback and reached through an SSH tunnel rather than exposed to the internet.
The defaults are chosen to fail closed. Dotfiles are refused, server tokens are off, and the container runs with the least privilege the software needs. None of this makes a system invulnerable; it removes the easy ways in.
Backups, and proof they work
A backup that has never been restored is a guess. We set up scheduled backups that leave the server, keep them for a defined period, and then prove the restore path on a real copy — not just that the job exited zero. The restore procedure is written down where the person on call can find it, with the exact commands and the expected result.
Backups contain the data you would most hate to lose, so they are encrypted, access is limited, and they are never left in a web root or a public bucket.
Self-hosted services
Some services are better run by the company that depends on them. Email is the clearest example: self-hosting keeps mail away from third-party scanning, but it also means you own the deliverability and the operations. We run that stack for our own domain — mail, webmail and a locked-down admin interface — and we can run it for yours. More on email hosting.
Who this is for
Teams with an app or site already in production and no one to own the servers, founders who want the hosting designed with the product rather than bought at the end, and companies that have been told their current setup is a risk but not what to do about it. We will audit what you have, tell you what is actually dangerous, and fix it in order of risk rather than in order of novelty.