Engineering services
Cloud & DevOps
We set up and run the servers your product lives on, so a new version can go live safely — and be undone in minutes if something goes wrong.
Part of your product’s journey
Of the eight stages we run, this service covers Deploy. We also run the others.
What this makes possible
A surprising number of live systems exist only in the memory of the person who set them up. The server was configured by hand over several evenings, nothing was written down, and nobody can recreate it. That works until the person leaves, or the machine is lost. Or until a release fails at eight in the evening. Putting the previous version back then turns out to mean somebody editing files on the server by hand and hoping.
Our approach in more detail
The fix is to describe the whole setup in files kept alongside your code, so it can be reviewed, repeated and rebuilt. Everything that exists is written down. Changes are checked by a second person before they are applied. The private copy of the system used for testing changes genuinely resembles the live one, because both are built from the same description. Going back to the previous version becomes a matter of undoing an entry rather than an act of memory. This is unglamorous, and it is the difference between an incident lasting minutes and one lasting a night.
The route from code to live system follows the same principle. The software is packaged once, and that exact package is then moved up through each stage with a check between them, so what you tested is what goes live. What is running is always what the written description says should be running, rather than whatever somebody last applied from their laptop. Passwords and keys are held properly, backups are taken, and a restore is actually tested — because a backup nobody has restored is not a backup.
What you get
- Server setup written down, so the test and live copies match
- Builds packaged the same way every time, and locked down
- Containers, orchestrated where the traffic justifies it — and a straight answer when it does not
- An automated release process, with a check at each step
- Releases driven from one recorded source, never from a laptop
- Safekeeping of passwords and keys, backups, and a recovery plan
How we get there.
- 01
Assessment
We document what exists now: where things run, how a release currently happens, who holds the passwords, what is backed up, and whether anybody has ever tried restoring it. This usually turns up at least one thing that would bring the whole system down on its own and that nobody had named. It also finds one piece of software still running on a version its makers no longer support.
- 02
Writing the setup down as code
Networks, servers, databases, storage and access all described in files, and changes applied only after review. Every environment comes from the same description with a few values changed between them, which removes the whole class of failure where something works in testing and not on the live system. The record of what currently exists is stored centrally and locked, so two people cannot make conflicting changes at once.
- 03
Packaging and running the software
Each release is packaged into a container — a sealed bundle holding the application and everything it needs to run, so it behaves the same wherever it is started. The bundles are built on minimal, hardened foundations, with the exact version of every library recorded, and are scanned for known vulnerabilities before release. Kubernetes is the tool that runs and manages large numbers of these bundles. Where it is genuinely warranted, we configure it properly. That means sensible limits on what each part may consume, health checks that mean something, and automatic scaling driven by a signal that reflects real demand. Where it is not warranted, we say so and use something simpler.
- 04
From code to live
One automated route that builds, tests, scans and produces a single package. That same package then moves through the private testing copy and on to the live system, with a check at each stage. What is running is kept in step with the written description, so anything that has quietly drifted away from it is visible. Releases are made routine enough to happen during working hours.
- 05
Passwords, backups and recovery
Credentials moved into a dedicated store that can change them on a schedule, access limited by role, and backups scheduled with a stated retention period. Then a written recovery procedure, and a restore actually carried out against it, with the time it took written down. How long recovery takes becomes a known number rather than an assumption.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if the application cannot tolerate any interruption at all. Some steps need a short planned pause, and pretending otherwise is how an unplanned one happens instead.
- Not for you if nobody on your side can grant us access to your hosting accounts. We cannot manage a system through somebody forwarding screenshots, and we will not ask for shared master passwords as a way around it.
- Not for you if you want Kubernetes because it is the fashionable answer. For a single application with modest traffic it adds work you pay for every month. We will propose the simpler thing and explain what you give up.
- Not for you if there is no plan for who runs this afterwards. Good infrastructure still needs an owner, and handing it to a team with no spare capacity recreates the original problem with better tools.
- Not for you if cutting cost is the only goal and the current bill is already small. The saving will not cover the engagement, and we would rather tell you than take the work.
A worked example
Hypothetical scenario
Illustrative: taking over a hand-built environment
Say your product runs on a few virtual machines set up two years ago by a developer who has since left. Releases are a script somebody runs by hand. There is no separate copy of the system for testing changes. The database backs up nightly to a storage bucket nobody has ever restored from. Work of this shape starts by changing nothing. First we write down what exists, as code, and confirm the description matches reality. Then the urgent gaps close in order of what would hurt most. A restore is tested. Passwords move out of the release script into a proper store. The security certificate due to expire next month is set to renew itself. Only then does the shape of things change. Packaged builds, and a real testing copy built from the same description as the live system. An automated release route replacing the hand-run script, and a way of putting the previous version back that takes seconds. A move of this kind runs six to ten weeks with the system live throughout, and the order of the steps matters more than the destination.
An illustration of our approach, not a delivered client project.
How long does this take?
A fresh setup with an automated release route, for a single application, is three to five weeks. Taking over an existing hand-built setup while it stays live is six to ten. Work across several environments with compliance requirements runs longer. The drivers are how many separate services there are, whether data has to move between hosting providers, and how much of the current setup nobody ever wrote down.
Who holds the cloud accounts and the credentials?
You do. The accounts are yours, the bill goes to you directly rather than through us, and we work under named roles with limited permissions you can withdraw in a minute. We do not resell hosting, and we do not want your live-system passwords sitting in our password manager. Emergency access is documented and recorded.
Do you cover out-of-hours, and how does that work across timezones?
We work from Mumbai, which overlaps about four hours with the UK and Europe, and two to three with the US East Coast. Where your busiest traffic sits outside our day, we agree an on-call arrangement with a defined response time written into the contract, rather than a vague promise of availability. If you need genuine round-the-clock cover, we will say plainly that a team of our size cannot provide it.
Will this reduce our cloud bill?
Often, because hand-built environments carry oversized machines, forgotten resources and storage nobody ever set to expire. We will not quote a percentage before looking. What we commit to is showing where the money goes, and labelling resources so future spending can be traced back to a product or a team. We also flag where a cheaper option carries more risk, so the trade-off stays yours.
Can our developers still release changes themselves?
That is the intended outcome. Releasing becomes merging a change into the main copy of the code, and the automated route handles the rest. We document the process, run a session with your team, and stay available while they get comfortable. If you would rather we operate it, that runs as a maintenance arrangement — but the point of writing it all down is that you are not obliged to.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.