Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
What DevOps management includes, and what it doesn't The work a DevOps management service should cover each month, the deliverables you should own at the end, and the gaps to settle before you sign.
Two proposals for 'DevOps management' can describe completely different jobs. One vendor means they will keep your servers patched. Another means they will own every release, every alert and every certificate. Both use the same words, and the difference only shows up the first time something breaks at night.
The short answer: a DevOps management service runs the path from a merged commit to a working production system. That covers CI/CD pipelines, environments, infrastructure and its configuration, monitoring and alerting, incident response, patching, backups with tested restores, access control and documentation. It does not usually include writing features or fixing application bugs.
This guide breaks that down into what should happen each month, what you should own at the end, and the boundaries worth writing into the agreement. It is based on how we run delivery for the systems we look after, from single VPS deployments on Dokploy to campus servers hosting many APIs and databases.
The core scope, area by area A complete service touches seven areas. A proposal that leaves one out is not necessarily wrong, but you should know which one and who covers it instead.
CI/CD pipelines: building, testing and deploying every change, including database migrations, environment approvals and a rollback path. On GitHub Actions, Jenkins or Azure DevOps, depending on where your code lives. Environments: development, staging and production kept separate, each with its own configuration, secrets and domain, and close enough to each other that staging tells you something useful. Infrastructure: servers, containers, networking, reverse proxy (NGINX or Traefik), DNS and TLS certificates, written down as code or at least as reproducible scripts. Monitoring and alerting: uptime checks, CPU, memory and disk, error rates, certificate expiry and backup success, with alerts routed to a named person. Incident response: someone who picks up the alert, diagnoses it, restores service, and writes a short note on what happened and what will stop it recurring. Patching and upgrades: operating system security updates, container base images, language runtimes (Node.js, Python), database versions (PostgreSQL, MongoDB) and pipeline actions, all kept inside their support windows. Backups and recovery: scheduled database and file backups stored off the server, with a restore rehearsed on a schedule. Access management sits across all of these. Who can deploy, who has SSH, which secrets live where, and how access is removed when someone leaves. It is easy to forget and is often the first thing an audit flags.
What should happen every month Most of the value in a managed service is routine, not heroic. When we take on a retainer, the recurring work looks roughly like this:
Weekly: review alerts that fired and any that were noisy, check disk growth trends, confirm the last backup completed and has a sensible size. Monthly: apply operating system and container image updates through staging first, review dependency and security advisories, check certificate and domain expiry dates, review who has access. Quarterly: restore a backup to a scratch environment and test the application against it, review hosting costs against actual usage, check upcoming end-of-life dates for runtimes and databases. Continuously: keep pipelines green, fix flaky steps rather than re-running them, and update runbooks whenever a procedure changes. Much of the weekly check can be scripted, so the review is about reading results rather than logging in to every server. A minimal version on an Ubuntu host looks like this:
# Certificate: exits non-zero if it expires within 21 days
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -enddate -checkend $((21*24*3600))
# Backups: warn if no dump has been written in the last 24 hours
find /var/backups/postgres -name '*.dump' -mmin -1440 | grep -q . \
|| echo "WARNING: no recent PostgreSQL backup"
# Disk: usage on the volumes that usually fill up first
df -h --output=target,pcent / /var/lib/docker
# Pending security updates
apt list --upgradable 2>/dev/null | grep -- -securityEach item on the routine should have a command or dashboard like this behind it, not just a promise.
Ask a prospective provider to show you this calendar for your systems. If the answer is 'we monitor everything and respond to issues', the preventive half of the work is probably missing.
A pipeline you can actually rely on Pipelines are where a managed service shows its quality most clearly. A good one is boring. Deploys to production need an approval, two deploys never run at the same time, and the artefact that passed staging is the one that goes live, rather than a fresh build from the same branch.
Approvals: on GitHub Actions, a production environment holds its own secrets and can require a reviewer before the job starts. Required reviewers on private repositories depend on your GitHub plan, so check this before you rely on it. Azure DevOps offers the same through environment approvals and checks. Serialised deploys: a concurrency group with cancel-in-progress set to false makes a second deploy wait rather than killing one halfway through a migration. GitHub keeps only the newest pending run per group, so a burst of pushes deploys the latest commit, not each one in turn. Traceable releases: images are tagged with the commit SHA and promoted from staging to production by tag, so anyone can see exactly which commit is live and roll back to the previous tag. Least privilege: the workflow token is read-only by default, deploy keys are scoped to one environment, and third-party actions are pinned to a version or commit. None of this is advanced, but a managed service should get it right on day one. Ask a provider to show you one of their existing pipelines.
What is usually not included Most disputes in DevOps retainers come from work that sits near the boundary. Settle these in writing before you start:
Application bugs. If a deploy fails because a test fails, the pipeline worked. Fixing the code is development work unless the agreement says otherwise. New features and new services. Adding a fresh microservice, queue or database is a change request, even if the provider will be the one running it. Major migrations. Moving from one cloud to another, or from Jenkins to GitHub Actions, is a project with its own scope, not part of the monthly fee. Third-party outages. A provider can detect and communicate a cloud region or payment gateway outage, but cannot fix it. Cloud spend. Infrastructure bills are normally paid by you, in your own account. Management covers keeping them sensible, not paying them. Coverage outside agreed hours. Response times and coverage hours should be agreed in the retainer. Anything beyond that is either extra or not covered. None of these exclusions is a warning sign. Vague scope is. 'Full DevOps support' with no list of exclusions usually means the boundary will be argued about later.
What you should own at the end A managed service should make you less dependent on any one person, including the provider. That only works if the outputs live with you. We hand over, and keep current, the following:
All cloud accounts, domains, DNS and repositories registered to your organisation, with the provider added as a user rather than as the owner. Pipeline definitions, Dockerfiles, Compose files or Kubernetes manifests, and infrastructure scripts in your repository. Secrets stored in your secret manager or CI environment, not in a provider's password vault. Runbooks for deploying, rolling back, restoring a backup, rotating a credential and handling the three or four incidents you see most. An architecture note: which services run where, what talks to what, and which ports and domains are exposed. An incident log and a short monthly report of what changed, what alerted and what is coming up. A useful test: if the provider disappeared tomorrow, could a competent engineer you hire next month deploy, roll back and restore from what is in your accounts? If not, the service is building lock-in, whether anyone intends it or not.
Setup project or ongoing management? Not every team needs a retainer. If you have developers who are comfortable running servers but lack a solid pipeline and environment setup, a fixed-scope setup project followed by a clean hand-over is often the better buy. If nobody on your team wants to be paged, or releases keep stalling because one person holds the keys, ongoing management makes more sense.
A middle path is a one-off audit. A reviewer looks at your pipelines, hosting, access and backups and gives you a prioritised list. You then decide which items to do yourselves and which to hand over. Pricing for each of these depends on the number of services, environments and integrations, and on the response times you need, so treat any quote that does not ask about them with caution.
Checklist before you sign Get the scope as a list of the seven areas above, with anything excluded named explicitly. Ask for the weekly, monthly and quarterly routine for your systems, in writing. Confirm coverage hours, response times and escalation contacts are agreed in the retainer. Check that accounts, repositories, domains and secrets will be in your organisation's name. Ask when the last restore test was done on a system they run, and what it found. Agree what the monthly report contains and who receives it. Agree how the service ends: what is handed over, and how access is removed. If a provider can answer all of these clearly, you will know what you are paying for each month. If they cannot, it is better to find that out now than during your first outage.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789