Development
DevOps
Build, release and operations: environments and secrets, a pipeline that can roll back, backups with a restore rehearsal, logs and alerts in one place.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 2 weeks
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Days 1–3
Deployment as it is
We look at how the product is built and shipped today: what builds the image, or what gets copied onto the server by hand, where the secrets sit, who holds access, what a rollback does. That gives a map of what exists and a list of the places where releasing depends on one person.
You get — A deployment map and who it depends on
Days 4–10
Environments and config
We settle the environments: how many there are, how staging differs from production, where it takes its data from. Configuration moves out into variables and the infrastructure is described as code — so that one and the same build goes to staging and to production instead of being rebuilt for each.
You get — Environments split and infrastructure as code
Weeks 2–3
Pipeline and rollback
The pipeline goes in: build the image, run the tests, deploy to staging on a button by the end of the second week, roll back to the previous version in minutes rather than in an evening. SSL, a liveness check and backups are set up alongside it.
You get — A build pipeline with rollback, SSL and backups
Before the cutover
The cutover
Production traffic moves across, but the switch and the rollback are rehearsed on a copy first, not on live users. Restoring from a backup is its own step — a backup nobody has ever restored from does not count as one.
You get — A rehearsed switch and a backup restored from
After the cutover
Monitoring and upkeep
Monitoring and logs are set up so that you hear about a failure before your users do, and so that the only thing that wakes anyone is worth getting up for. After that: base images updated, keys rotated, and the infrastructure bill read through — there is usually an environment on it that was spun up for a week and never turned off.
You get — Alerts before your users and the bill read
What the work covers
Deployment as it is today
written down off the running server, an inventory of services and domains, access per person, secrets and where they sit.
Environments and configuration
the line between staging and production, settings in variables, secrets out of the repository, infrastructure as code.
The build pipeline
one image for every environment, tests before the deploy, a button instead of hand-typed commands, a way back without rebuilding.
Backups
a schedule, storage away from the server, a restore actually carried out, and a measurement of how long it takes.
Monitoring and alerts
logs in one place, metrics for the server and the application, a liveness check from outside, the threshold that sends a message.
Moving to new hosting
switch and rollback rehearsed on a copy, domain and certificates with auto-renewal, a downtime window fixed in advance.
What we need from you
- Access to the servers and to the account they are held under, together with control of the domain’s DNS.
- Whatever stands in for a deployment guide today — commands in somebody’s head, a script on the server, a thread in chat.
- A downtime window we can agree on for moving the live database, and someone on your side reachable while it runs.
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.