How our DevOps team runs production for clients: tooling, on-call and standards

A managed DevOps team runs your production environment through a repeatable set of habits, not a single tool: an onboarding audit before anything changes, least-privilege access, a hardened baseline, deployments that can be rolled back, alerts tiered by severity, tested backups, a steady patching cadence, and a written process for incidents and the post-mortems that follow. This is how our DevOps team works with clients in Nepal and Australia — on our managed OVHcloud infrastructure, or inside your own cloud account.

What a managed DevOps team checks before touching your servers#

If you're still deciding whether managed DevOps is the right model for your team, read our DevOps as a service guide first — it covers cost and when this beats hiring. Once you're a client, the first job is not to make changes. We spend the first days building a written baseline: every server and service in use, DNS records and domain registrars, TLS certificate expiry dates, user accounts and SSH keys, cron jobs and scheduled tasks, open ports, OS and dependency versions, and the current state of backups and logging.

That baseline turns into a prioritised list of gaps: the things we fix in the first weeks, and the things we monitor and revisit later. Skipping this step and making changes on a live production system on day one is a common way for a well-meaning DevOps engineer to cause the outage they were hired to prevent.

Access control: least privilege, individual keys and MFA#

Everyone who touches production gets their own named account, never a shared root login passed around in a chat message. Access follows least privilege: a support engineer gets what a task needs, not full admin by default, and cloud IAM roles are scoped the same way. SSH access uses keys, not passwords. Multi-factor authentication is required on every control plane that matters — the cloud console, the domain registrar, GitHub, and any hosting panel.

When someone leaves a project, their access is revoked the same day, not at the next audit. Secrets — database passwords, API keys, third-party tokens — live in environment configuration or a secrets manager, never committed to a Git repository.

Baseline hardening before anything goes live#

Before an application goes live, the server it runs on gets hardened against the basics: a default-deny firewall that only opens the ports the application actually needs, SSH restricted to key-based logins with root login disabled, automatic installation of critical security updates, and removal of default accounts and unused services.

TLS is handled with Let's Encrypt and Certbot. Certificates are deliberately short-lived: Let's Encrypt issues 90-day certificates specifically so renewal has to be automated rather than left to someone remembering, so renewal runs on a schedule, not a reminder. We check new servers against a published hardening baseline, such as the CIS Benchmarks, rather than relying on memory of what "secure" is supposed to look like. Our Linux server hardening checklist sets out the fuller list we work through server by server.

Deployments that are repeatable, and easy to reverse#

A deployment should be boring: the same steps every time, scripted rather than remembered, with every release tagged in Git on GitHub so we always know exactly what code is running. Our Node.js applications — Next.js front ends, NestJS APIs — run under PM2, which supports a genuine zero-downtime reload: PM2's reload command replaces running processes without dropping connections, unlike a hard restart. Nginx sits in front as the reverse proxy, so traffic can point at a new release, or back at the previous one, without a gap.

Fully Managed clients also get a staging environment, so changes are tested somewhere that isn't production first. The point of all this discipline is simple: if a release causes a problem, rolling back should take minutes, not an emergency call to whoever wrote the code.

Monitoring and alerting, tiered by severity#

Not every alert deserves the same response, so we tier them. A critical alert — the site is down, the database is unreachable, disk space has run out — pages a human immediately under our Managed and Fully Managed plans, at any hour. A warning — memory climbing steadily, a certificate expiring in two weeks, disk usage trending upward — goes into a daily check rather than an overnight page. Informational metrics feed the monthly report instead of interrupting anyone.

The goal is a small number of alerts that are always worth acting on, rather than a flood of notifications that trains everyone to ignore them. We go deeper on choosing alerts that matter for a small team in monitoring vs observability for small teams.

Backups and restore tests, not just backups#

A backup file proves nothing on its own — the only backup you can trust is one you have actually restored. We keep backups off the server they protect, following a 3-2-1-style approach, and run restore tests on a schedule rather than assuming a nightly job worked because no error was logged.

Our guide to backups that actually restore sets out how we think about recovery point and recovery time objectives, and why "we have backups" and "we can recover within the time our business needs" are two different claims.

Patching cadence#

Operating system and dependency patches go on a regular schedule rather than waiting for a client to ask, with security patches prioritised over feature updates. For Fully Managed clients, patches go to staging first where a change carries meaningful risk; for simpler stacks, we use low-traffic windows to reduce the chance anyone notices. We would rather apply a patch on our own timeline than explain, after the fact, why a known vulnerability sat open for months.

Incident response and blameless post-mortems#

When something does break, the immediate job is to restore service and keep the client informed, not to find someone to blame. Fully Managed clients have a runbook for their most likely failure modes, so the first response doesn't start from a blank page.

Once the incident is resolved, we write a short post-mortem: what happened, why, and what changes — to monitoring, to the deployment process, to the infrastructure itself — make a repeat less likely. Our post on incident response, runbooks and blameless post-mortems covers how we structure this in more detail.

Monthly reporting and right-sizing reviews#

Managed and Fully Managed clients get a written monthly report: uptime, patches applied, backup and restore-test status, and any incidents with what we did about them. We use the same cycle to check whether the server is still the right size. An over-provisioned box is money spent on capacity nobody uses; an under-provisioned one shows up as slow pages long before it shows up as an outage. Right-sizing is a routine review, not a one-off decision made at setup and never revisited.

Running inside a client's own cloud account#

Some clients want to keep their own OVHcloud, AWS, Azure, Google Cloud or DigitalOcean account — for billing, ownership or their own internal reasons — and have us run it rather than move to infrastructure we sell. The standards above don't change: the same least-privilege access, the same hardening baseline, the same deployment and monitoring discipline, adapted to whichever console and IAM system that provider uses.

This "bring your own cloud" arrangement comes up often enough that it's one of the first questions we ask a new client, not an edge case we handle reluctantly.

Which plan includes what#

Our management levels build on each other. This is what typically changes between them — see current plans and prices for the up-to-date detail.

What to do next#

If you want this level of discipline applied to your own servers, our managed DevOps service page sets out what's included at each level. If you'd rather talk through what you're running today than read another page, get in touch and tell us where things stand.