DevOps Services
Shipping should not need someone watching the logs
Deploys that run the same way every time, with a check after each one and a way back if it fails. Part of the Operate plan.
Most teams start with the free AWS bill check. Once the bill is down, we review the rest of your setup for free, and this is one of the things we can take on. How the steps work
The deploy only one person knows how to do
Releasing a new version works, mostly. One developer knows the steps. They run a script, watch the logs, refresh the site a few times, and say "looks good" in the team chat. When they are on holiday, releases wait.
Sometimes a release goes wrong. Getting back to the previous version takes longer than anyone expected, because nobody has practiced it.
A release (or deploy) is putting a new version of your app live. A rollback is going back to the last version that worked.
What could happen
- A bad release during a launch. You ship a fix the morning of a campaign. It breaks checkout. The way back is a manual set of steps nobody has written down, and it takes two hours (example).
- Releases slow down. Because each one is stressful, the team ships less often. Changes pile up, and every release gets bigger and riskier.
- One person is the bottleneck. If the passwords and the steps live in one head, every holiday is a risk. If that person leaves, so does the knowledge.
- Database changes that can't be undone. A release changes how data is stored. Rolling back the code is easy; rolling back the data is not, unless someone planned for it.
- "It worked on my machine." Versions differ between a developer's laptop, staging and the live servers, so things that passed testing fail in production.
What we do, step by step
You focus on shipping. We make the shipping part boring.
- Write down how releases work today. A senior engineer walks through your current process with the person who does it, and writes every step down. This alone removes the one-person risk.
- Automate the steps. The same steps run the same way every time, from your code hosting, with a button or a merge. Settings and secrets come from one place, not from a laptop.
- Check before it goes live. Automated tests and basic checks run first: the app builds, starts, and key pages answer. If a check fails, the release stops before customers see it.
- Release in a way that can be undone. Where your setup allows, the new version starts next to the old one and traffic switches over only when it is healthy. Database changes are reviewed by a senior engineer for whether they can be reversed.
- Watch the first minutes. After each release, our monitoring compares error rates and response times with the previous version. Software spots the change; an engineer decides whether to roll back.
- A one-step way back. Rolling back to the last working version is a single, tested action, and we practice it with you.
- Handle it when it fails. On Operate, if a release breaks something, we handle the incident and tell you in plain words what happened and what we changed.
Nothing changes until you approve it
No change skips a step
The same path for a one-line config tweak and for a database move. Here is change 014, an example.
Written up
What, why, cost, and the way back
You approve
In writing, by the person you named
Backup taken
A fresh copy before anything moves
Applied
At the time you picked
Checked and logged
App tested from outside, note sent
What you can do yourself today
- Write your release steps in a shared document, exactly as you run them. Ask someone else to follow them once.
- Find out how long it takes to go back to the previous version. Try it on staging.
- Move secrets out of laptops and into your hosting provider's settings or a shared vault.
- Pick one check to run before every release, even a simple "does the homepage load," and make it automatic.
- Avoid releasing on Friday afternoons until your rollback is tested.
What's included in which plan
| Guard $700/mo | Watch $1,200/mo | Operate $2,800/mo | |
|---|---|---|---|
| Releases handled, with a way back if one fails | No | No | Yes |
| Incident handling when something breaks | No | No | Yes |
| Uptime checks after each release | No | Yes | Yes |
| Software updates, tested before they go live | Yes | Yes | Yes |
| One engineer who knows your setup | No | No | Yes |
Operate setup is quoted after the free review, because it depends on how your releases work today. Month to month, no exit fee. See all plans.
If you are not on Operate and just want your release process set up once, ask in the review form. We quote it as a fixed-price project before any work starts.
Questions about releases
Does this change how our developers work?
As little as possible. Your team keeps writing code and merging it the way they do now. What changes is what happens after the merge: the same checked steps every time, instead of someone running them by hand.
Who decides when something goes live?
You do. Releases follow your rules: on merge, on a button, or at set times. We don't release your code without your team's say-so.
What if a release breaks the database?
That is the hardest case, so we look at database changes before they ship and plan how to undo each one. If a change can't be undone safely, we tell you before it goes out, and make sure a fresh backup exists first.
Do you need write access to our code?
Usually we need access to the release settings in your code hosting and your hosting account, not to your code itself. Every action is logged and visible to you, and you can remove our access in one step.
How we work with your systems
You stay in control
Read-only access first
The free bill check needs read access and nothing else. Nothing in your systems changes.
You approve every change
Each change comes as a short written note first: what, why, and how to undo it.
Your data and billing stay yours
Everything stays in your own account. We never become your billing contact.
Every action logged
Every action we take is logged, and the log is visible to you.
One-click access removal
Delete the access role and our access ends at once, with no penalty.
Month to month
There is no minimum term and no exit fee. Stop at the end of any month.
Your free AWS bill check, in 48 hours
One read-only template. Every dollar you could stop paying, ranked. You keep the report even if you never hire us.
read-only accessno savings, no feemonth to month
