Run
Cloud & DevOps
Kubernetes, CI/CD and infrastructure-as-code — so deploying on a Friday stops being a topic of debate.
Infrastructure work pays off in things that stop happening: the deploy that does not need a war room, the outage that resolves itself, the migration nobody notices. That makes it easy to underfund and expensive to neglect.
The symptom is usually the same. Deployment is a ritual only one person can perform. Nobody is sure which configuration is live. Staging diverged from production two years ago and everyone has stopped trusting it. None of that is exotic, and none of it gets better on its own — it compounds quietly until an incident makes it everyone’s problem at once.
We run production Kubernetes on our own infrastructure as well as our clients’, and we have the scars to prove the difference between a cluster that works and a cluster that works at 3am. Where managed services are the right answer, we will say so rather than bill you for complexity. Kubernetes is not a default; it earns its place when you have enough services to justify the operational overhead, and quite often you do not.
GitOps by default: the cluster state lives in a repository, changes arrive as reviewable commits, and rollback is a revert rather than an improvisation. It is a slower way to make a change and a dramatically faster way to undo one, which is the trade you want under pressure.
The goal is not sophistication. It is that a new engineer can deploy safely in their first week, and that the person who knows how it works going on holiday is not a business risk.
What is included
- Assessment of what you run now, and what it costs you
- CI/CD pipelines with tests, build and deploy stages
- Infrastructure as code — Terraform, Helm, or the equivalent
- GitOps delivery, with cluster state under review in a repository
- Observability: metrics, logs, traces and alerts that mean something
- Secrets management and access control
- Backup and restore, tested rather than assumed
- Runbooks and an on-call handover your team can actually use
What we do not do
- Kubernetes where a managed platform would serve you better
- Alerting so noisy that people learn to ignore it
- Migrations with no rollback path
- Ongoing operations we hold exclusively, leaving you unable to function without us
How the work runs
- 01
Map the current state
What runs where, who can deploy, what happens when it breaks. Usually this surfaces two or three things nobody had written down.
- 02
Make deployment boring first
Before any platform work, we make shipping repeatable and reversible. Everything else is easier once you can deploy without ceremony.
- 03
Move state into code
Infrastructure described in a repository, changes as pull requests. This is where “which config is live?” stops being a question.
- 04
Prove the recovery path
Restore from backup, fail over, roll back — performed rather than documented. A recovery plan nobody has executed is a hypothesis.
Where we have done this
Two projects you can read in full.
A marketplace with games inside it, and the pipeline that ships it
A React Native marketplace app with Unity games embedded in it, running on self-managed Kubernetes with GitOps delivery — where a deploy is a commit and a rollback is a revert.
StratoformA building that assembles itself as you scroll, for a factory that has not opened yet
Stratoform sells precast concrete into an Indian construction market that still mostly pours on site. They had no finished building to photograph and no production floor to film — the German casting line was still being installed. So the site makes the argument structurally instead: scroll, and a three-storey frame goes up element by element, each one labelled with the spec it would carry on a drawing.
Shipped with
- React Native
- Unity
- Express
- Redis
- BullMQ
- Kubernetes
- Helm
- Rancher Fleet
- Traefik
- Docker
- Next.js
- React
- Three.js
- WebGL2
- Lenis
- k3s
- nginx
- Let's Encrypt
Taken from the projects above, not from a list of things we have read about.
Capabilities
- Kubernetes and container orchestration
- CI/CD pipeline design
- Infrastructure as code (Terraform, Helm)
- GitOps delivery workflows
- Cloud migration and modernisation
- Observability, logging and alerting
- Cost optimisation
- Disaster recovery and backup strategy
- Zero-downtime deployment strategies
- Autoscaling and capacity planning
- Secrets management and access control
- Self-hosted and hybrid infrastructure
Questions we get asked
Do we actually need Kubernetes?
Often not. It earns its operational overhead when you are running enough services, with enough scaling variability, that orchestration saves more than it costs. For a single application with predictable load, a managed platform is usually cheaper, simpler and easier to hire for. We will tell you which situation you are in before proposing work.
Which cloud providers do you work with?
The major providers, and self-hosted or hybrid infrastructure where that suits your cost profile or data residency requirements. We run our own production workloads on self-managed infrastructure, so the trade-offs are ones we live with rather than ones we have only read about.
Can you migrate us without downtime?
In most cases yes, using parallel running and staged cutover, though it costs more than a maintenance window and is not always worth it. We will price both and let you choose. What we will not do is attempt a cutover with no tested way back.
How do you approach cloud cost?
By measuring first. Most overspend concentrates in a few places: oversized instances, storage nobody deleted, data transfer nobody accounted for, and non-production environments running around the clock. Those are usually addressable without touching architecture.
Will our team be able to run this after you leave?
That is the explicit goal. Everything lives in your repositories and your accounts, with runbooks written for someone who was not present when it was built. We would rather hand over cleanly than hold a dependency — a client who cannot operate without us is a liability for both of us.
Do you offer ongoing support or on-call?
Yes, sized to the system’s real criticality rather than a standard tier. For many clients that is business-hours support with an escalation path, not a 24/7 rotation they are paying for and never using.