What a DevOps retainer actually buys — and where outsourced DevOps goes wrong

Most DevOps-as-a-Service pitches sell you a project: we will set up your CI/CD, containerise your app, write your Terraform, wire up Prometheus and Grafana. All of that is real, and for a small or well-understood estate much of it is done in a few weeks — a larger, regulated or legacy environment takes longer and is more iterative. Then the retainer starts, and the retainer is not the project. It is the operational tail the project created — and if you do not know what fills it, you cannot tell whether you are paying for work or for a phone number.

Here is the honest version of both halves: what the monthly fee actually buys, and the ways paying someone else for it goes wrong.

Why it is a retainer and not a project

A pipeline that works today does not stay working on its own, because everything underneath it moves. A base image ships a CVE. A dependency has a breaking major release. The cloud provider deprecates an API version. A TLS certificate expires. A runner image updates and a build step that relied on the old one silently changes behaviour. Pinning dependencies and runner images keeps the surprises down, but none of this can be ignored forever — the only question is whether you act on your schedule or on the incident's. Managed decay is the workload.

That is the mental model that makes the fee legible. You are not paying for CI/CD to exist. You are paying for it to keep existing while the ground shifts under it.

What actually fills the month

A retainer that is earning its fee is doing most of this, most months:

• •Pipeline upkeep. Runner and base-image updates, dependency bumps, fixing the build that broke because something upstream changed.
• •Patching and CVE response. Watching for vulnerabilities in images and dependencies, triaging by real exposure, and rolling the fixes that matter before they become the incident.
• •Infrastructure drift and IaC upkeep. Keeping Terraform (or equivalent) matching reality, catching the change someone made in the console at 2am, upgrading provider and module versions.
• •Cloud cost control. Spotting the orphaned volume, the oversized instance, the environment nobody turned off — often paying for a meaningful slice of its own fee here.
• •Monitoring and alerting. Tuning alerts so they fire on real problems and not on noise, which is ongoing because what counts as normal keeps changing.
• •Incident response and the on-call path — where the contract provides for it. This is the part you are really buying: someone who answers when it breaks and knows the system well enough to fix it fast.
• •Secrets and certificate rotation. The boring, scheduled work that becomes an outage precisely when it is skipped.
• •Lifecycle management. Kubernetes, the cloud provider and the tooling all move; someone has to track the deprecations and end-of-life dates that affect you and plan the upgrades, so a supported-version cutoff is a calendar item and not a fire.

If a retainer is not visibly doing these, you are paying for availability, not work — a legitimate thing to buy, but you should know that is what it is.

Where outsourcing it goes wrong

This is the part the sales pages leave out, and it is where we would rather be honest than win a bad-fit contract.

• •The bus factor moves outside your walls. A single in-house engineer who alone understands your infrastructure is a known risk. Outsourcing to one external engineer does not remove that risk, it relocates it somewhere you control even less. If the provider is one person with your estate in their head, you have the same single point of failure with a contract wrapped around it.
• •The black box. "DevOps handles it" curdles into nobody on your side understanding how the estate works. That feels efficient until you want to change provider, bring it in-house, or simply make a decision that needs someone internal to weigh the trade-off — and there is no one.
• •Lock-in by default. If the infrastructure lives in the provider's accounts, the pipelines in their tooling, and the knowledge in their private notes, leaving is a migration, not a notice period. Lock-in is rarely malicious; it is just what happens when nobody designed against it.
• •Cold-start at 3am. An external team without standing context and access can be slower in the first minutes of an incident than an insider who already knows where everything is — unless the relationship is deliberately built to keep them warm.

How a retainer should be built to not do that

The failure modes above are not arguments against outsourcing DevOps. They are the specification for doing it well, and the questions to ask any provider, us included:

• •Everything as code, in your repository — pipelines, infrastructure, runbooks — not in the provider's private store.
• •Infrastructure in your cloud accounts, under your billing and your ultimate control, not the provider's.
• •More than one engineer who knows your estate, so the provider's own bus factor is greater than one — the honest reason real round-the-clock cover needs redundancy behind it, not a single hero.
• •Documentation and runbooks written to be handed over, on the assumption you might one day leave — which is exactly what makes staying a choice rather than a trap.

A provider that resists any of these is selling you the lock-in, not guarding against it.

When you should not outsource DevOps at all

Because we would rather tell you now than three months in: keep it in-house when DevOps is your actual product differentiator and the expertise has to compound inside the company; when your scale is large and steady enough that a full-time hire is both cheaper and more available than a retainer; or when the work genuinely needs someone in the room with the product team every day. Outsourcing is at its best for the many companies in between — real operational needs, not enough of them to justify a full-time senior hire, and no wish to become a DevOps employer just to get one.

What we do

We run DevOps as a service from €500/month per project for a defined scope, and the shape of it is the specification above: your repo, your accounts, more than one engineer who knows your systems, and documentation that would let you leave. The fee buys the decay-fighting — the patching, the drift, the cost control, the answer when it breaks — and it is built so that if it ever stops earning its keep, you can see that it has and act on it. The worst outcome in this business is a client who cannot tell whether they are paying for work or for silence. We would rather you always could.