"Managed DevOps" means very different things depending on who is selling it. For some it is a Jenkins server and a monthly invoice. For others it is a team that owns your entire path from a Git commit to production and answers the pager at night.
This guide sets out what a complete service covers, so you can compare providers on scope rather than on the label.
What managed DevOps means
A managed DevOps provider builds and then operates the systems that get your code into production and keep it running there. The operating part is what separates it from a one-off project. Someone is responsible for those systems every day, not just on the day they were delivered.
What a complete service should include
Build and deploy
- CI/CD pipelines in GitHub Actions, GitLab CI, Jenkins or similar: build, test, security scans and deploy on every merge.
- Containers: reproducible Docker images, a private registry, and image scanning.
- Deployment strategy: rolling, blue-green or canary releases with health checks and a fast rollback.
- Environments: staging that matches production closely enough to catch problems before release.
Infrastructure
- Infrastructure as code (Terraform, OpenTofu, Pulumi, CloudFormation or Ansible) stored in your Git repository, so every change is reviewed and repeatable.
- Orchestration where it is justified: managed Kubernetes (EKS, GKE, AKS), lighter options such as ECS or k3s, or plain servers.
- Secrets management: credentials in a vault or the cloud provider's secret store, not in code or CI variables shared by everyone.
Running it
- Monitoring and alerting on the application, servers, databases and pipelines, with someone actually responding to the alerts.
- Incident response with agreed response times and a written follow-up explaining the cause and the fix.
- Upgrades: Kubernetes versions, runtimes, base images and dependencies kept current, so you are never stuck on an end-of-life version.
- Backups and recovery: scheduled, stored off-site and tested with real restores.
- Security hygiene: patching, least-privilege access, audit logs and regular access reviews.
- Cost reviews: rightsizing and removing unused resources as traffic changes.
Documentation
- A current diagram of the architecture.
- Runbooks for common incidents and for releasing, rolling back and restoring.
- A list of every system, account and credential owner.
What usually isn't included
Ask about these explicitly, because they are often billed separately or not covered at all:
- Writing or fixing application code. Some providers will debug a failed build, but not the feature that broke it.
- Major projects, such as a migration to Kubernetes or another cloud, beyond the monthly scope.
- Database administration beyond backups and basic tuning.
- Third-party tool licences and cloud costs, which you pay directly.
- Compliance audits (SOC 2, ISO 27001, HIPAA). A provider can prepare evidence and controls, but the audit itself is separate.
Managed DevOps vs in-house vs a freelancer
| In-house engineer | Freelancer | Managed DevOps team | |
|---|---|---|---|
| Cost | Full salary and benefits | Hourly or per project | Monthly fee for a defined scope |
| Cover at nights, weekends and holidays | One person, unless you hire several | Usually none | Shared across the team |
| Knowledge if someone leaves | Leaves with them unless documented | Often leaves with them | Documented and shared by the team |
| Product knowledge | Deepest | Limited | Grows over time |
| Best for | Large or complex platforms with constant change | One-off projects | Teams that need production run reliably without a full DevOps hire |
Many companies combine them: an in-house engineer who owns the platform, with a managed team covering out-of-hours incidents, upgrades and routine work.
How managed DevOps is priced
Providers typically use one of three models, or a mix:
- Fixed monthly retainer for a defined scope (number of environments, clusters or servers, and response times). Predictable, but check what happens when you exceed the scope.
- Per server or per environment. Easy to understand for server-heavy setups, less so for serverless or Kubernetes platforms.
- Project plus retainer. A fixed quote to build or fix the platform first, then a smaller monthly fee to run it.
Whatever the model, get the scope and price in writing before work starts. A quote you can't compare line by line with another provider's isn't a quote.
10 questions to ask before you hire
- Who responds to an incident at 3 a.m., and how quickly? Ask for response times in writing for each severity level.
- What exactly is in scope each month, and what is billed extra?
- Where does the infrastructure code live? The answer should be "in your Git repository".
- Whose cloud accounts are used? They should be yours, with the provider given access, never the other way round.
- How do you handle secrets and access? Look for named accounts, MFA, least privilege and an audit trail.
- How are changes reviewed and approved? Infrastructure changes should go through pull requests like application code.
- When did you last test a restore, and how?
- What will we receive each month? For example, an incident summary, upgrade status and cost changes.
- Can we talk to a current client?
- How do we leave? Ask for the exit process in the contract.
Red flags
- The provider wants to host your infrastructure in their cloud account.
- Infrastructure is changed by hand in the console, with no code or record.
- Nobody can tell you who is on call this weekend.
- No documentation is offered, or it is "available on request" and never arrives.
- Every recommendation adds complexity, such as Kubernetes for a single small application.
What the first month should look like
- Access and inventory. Named accounts with MFA, and a list of every system, account, domain and certificate.
- Review. A written report on what exists, the biggest risks, and quick wins.
- Monitoring first. Alerts connected before any major changes, so nothing breaks unnoticed.
- Backups verified. At least one real restore test.
- Plan. An agreed list of improvements in priority order, with anything outside the monthly scope quoted separately.
When it makes sense
Managed DevOps is a good fit if deploys are manual or fragile, production depends on one person who can't take holiday, or nobody is watching the systems out of hours. It is less useful if you already have a stable platform team that only needs occasional specialist help.
If you'd like to see how we approach it, our managed DevOps service builds pipelines and infrastructure as code in your own repositories and accounts, then runs them in production. For teams on AWS, it works alongside AWS managed services and cloud server management.
