On-premise and bare-metal infrastructure
If your software cannot live on someone else's cloud, we build and run it on your own hardware — properly, with the same pipelines and observability.
Not every system belongs in a public cloud. Sometimes the reason is regulatory: a supervisor, a client contract or a data protection regime requires that data stay on hardware you control. Sometimes it is sovereignty: a defence, pharmaceutical or government programme where a third-party operator is not acceptable at any price. Sometimes it is simply arithmetic — at steady, predictable, high load, owned hardware is materially cheaper than renting it, and the crossover point arrives earlier than cloud vendors suggest.
The usual problem with on-premise is not the hardware. It is that on-premise systems tend to be hand-built: one server somebody configured by hand three years ago, no reproducible provisioning, no deployment pipeline, no monitoring beyond someone noticing it is slow, and a restore procedure nobody has tested. That is not on-premise being worse than cloud — that is undisciplined infrastructure, and it happens to be easier to get away with when there is no billing dashboard forcing you to look at it.
We build on-premise the way we build cloud. Everything provisioned from code with Ansible so a rebuilt node is identical to the one it replaced. Containers orchestrated by Kubernetes or Docker Swarm depending on how much complexity your team should actually carry. Load balancing, TLS termination, deployment pipelines, metrics, logs, error tracking and alerting — the whole stack, running on your metal, operated by your team with our documentation.
We will also tell you when cloud is the right answer, which is often. Bursty or unpredictable load, small scale, a team with no appetite for hardware, or a need to be in six countries next year all point the other way.
The parts that matter.
- 01
Bare-metal orchestration
Kubernetes on your own servers where the workload justifies it, or Docker Swarm where it does not — Swarm is far simpler to operate and is the right answer more often than the industry admits. Ingress, TLS, storage and node failure behaviour designed rather than discovered.
- 02
Provisioning as code
Ansible playbooks and roles for every host, so a machine is reproducible from bare metal and a replacement is identical to the original. No hand-configured servers, no institutional knowledge living in one person's memory.
- 03
Load balancing and edge
HAProxy and Nginx for load balancing, TLS termination, rate limiting and failover, configured for real traffic patterns and tested by taking nodes out deliberately.
- 04
Observability you own
Prometheus for metrics, Grafana for dashboards and alerting, Loki for logs, Sentry for errors and PostHog for product analytics — all self-hosted, so telemetry about your operations does not leave your network either.
- 05
Deployment pipelines on-site
Jenkins or self-hosted runners with Argo CD for GitOps delivery, so deploying to your own hardware is the same one-click, one-click-rollback operation as deploying to a cloud.
- 06
Hybrid and repatriation
Keep regulated data on-premise and burst non-sensitive workloads to a cloud, or move a workload back from cloud where the economics have turned. Both are ordinary engineering rather than a rewrite, if the architecture was portable to begin with.
- 07
Capacity, resilience and recovery
Sizing against real projected load rather than a vendor's calculator, redundancy where a single failure would stop the business, backup targets you control, and a restore that has actually been performed and timed.
- 08
Runbooks and handover
Your team ends up operating this. Documented runbooks for the failures that actually happen, an on-call rotation that makes sense for your size, and working sessions until your engineers are comfortable.
What you
actually receive.
Named artefacts, not a status report. Every item here is something you can open, run or hand to another engineer.
- 01Ansible codebase provisioning every host reproducibly from bare metal
- 02Container orchestration on your hardware, with tested node-failure behaviour
- 03GitOps deployment pipeline with one-step rollback, running on-site
- 04Self-hosted observability: metrics, dashboards, logs, errors, product analytics
- 05Capacity plan and load test results against your projected peak
- 06Backup and disaster recovery with a restore that has been performed and timed
- 07Runbooks, architecture decision records and handover sessions with your team
Before you ask.
Do you supply the hardware?
No, we do not resell hardware — which means we have no incentive to over-specify it. We size the requirement, give you a specification you can buy from any vendor or colocation provider, and then build on what you procure. If you already have servers sitting underused, we would rather start there.
Kubernetes or Docker Swarm on bare metal?
Swarm more often than the industry suggests. It is dramatically simpler to operate, and for a handful of services on a handful of nodes it does the job with a fraction of the operational tax. Kubernetes earns its complexity at real service count, multiple teams, or when you need its ecosystem. We will recommend against Kubernetes when it is overkill.
Who operates it once it is built?
Your team, with our documentation — that is the goal, and the handover is a deliverable rather than a favour. We also offer a support retainer for patching, upgrades and incident escalation where you would rather not carry it alone.
Is on-premise actually cheaper?
At steady, predictable, high load, frequently yes — and the crossover comes earlier than cloud pricing pages imply, particularly for data egress and always-on compute. At low or bursty load, almost never. We model it over three to five years including hardware refresh, power, space, and the staff time to operate it, and we show you the workings.
Can we run some things on-premise and some in the cloud?
Yes, and it is a common and sensible end state: regulated data on your hardware, everything else wherever is cheapest. The thing that makes it possible is keeping the application portable — containers, no proprietary managed services on the critical path — which is a decision made at architecture time.
What about air-gapped environments?
We work with segmented and air-gapped networks, including offline package mirrors and registries so builds and updates do not require internet access. It changes the delivery process rather than ruling it out.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.