DevOps Coverage8 min readUpdated November 3, 2026

You Don't Need a DevOps Department. You Need Coverage.

We audited our own stack first and found an exposed admin panel and empty backup directories the cron claimed were running. Here is the read-only method, free to copy.

Coverage is not a headcount. It is a weekly read-only audit that answers three questions: who has access, what is exposed, and do the backups actually contain data.

We joined a client as their first DevOps engineers. The company had no DevOps function, so access management had grown by accident. During onboarding we found that a non-technical office employee held admin credentials to the production environment. Nobody had done anything malicious.

See How We Work

In This Guide

The cleaner had admin access to production

We joined a client as their first DevOps engineers. The company had no DevOps function, so access management had grown by accident. During onboarding we found that a non-technical office employee held admin credentials to the production environment. Nobody had done anything malicious.
We joined a client as their first DevOps engineers. The company had no DevOps function, so access management had grown by accident. During onboarding we found that a non-technical office employee held admin credentials to the production environment. Nobody had done anything malicious. There was simply never a process, so access accumulated like clutter in a storage room. This is not a horror story about that client. It is the default state of every startup that ships product without an infrastructure owner. The question is not whether this is happening at your company. It is whether you know where.

Coverage is three questions, not a salary

A DevOps hire gives you coverage, but coverage itself is cheaper than the hire. It reduces to three questions. First: who has access to what, including the accounts everyone forgot. Second: what is exposed to the internet right now, not what the diagram says. Third: if everything crashed tonight, would the backups actually restore.
A DevOps hire gives you coverage, but coverage itself is cheaper than the hire. It reduces to three questions. First: who has access to what, including the accounts everyone forgot. Second: what is exposed to the internet right now, not what the diagram says. Third: if everything crashed tonight, would the backups actually restore. Any process that answers these three questions weekly gives you most of the value of a DevOps function, at the cost of an hour and a script.

We audited ourselves first, and it hurt

Before pointing this at any client we ran the audit on our own stack. Two findings were P0 and both were invisible to any code review. Our reverse proxy admin panel was listening on a public port, the exact surface the audit checklist warns about because it is the most commonly forgotten one.
Before pointing this at any client we ran the audit on our own stack. Two findings were P0 and both were invisible to any code review. Our reverse proxy admin panel was listening on a public port, the exact surface the audit checklist warns about because it is the most commonly forgotten one. And our backup cron ran daily while its output directories were empty, because a config step inside the script had silently failed. The cron line looked perfect. The directories told the truth. That is why the audit verifies backups by listing output files, never by reading the schedule.

The read-only method

The audit runs in three layers. The repo layer checks for secrets committed to git, missing CI/CD gates, and Terraform state hygiene. The live layer checks what is actually running: public ports, TLS certificate expiry, restart policies, backup freshness, disk usage, failed services, SSH configuration.
The audit runs in three layers. The repo layer checks for secrets committed to git, missing CI/CD gates, and Terraform state hygiene. The live layer checks what is actually running: public ports, TLS certificate expiry, restart policies, backup freshness, disk usage, failed services, SSH configuration. The change-safety layer validates infrastructure code against an emulated cloud before it touches production. Every command is read-only. Every finding gets a verdict: confirmed, needs validation, or rejected. Priority is assigned only to confirmed items, because an audit that cries wolf gets ignored.

The skills are free, copy them

We packaged the audit as agent skills: infra-readiness-audit for the repo layer and live-infra-audit for the live layer. They are Apache licensed, they contain the exact commands and the priority model, and they run on any agent that can execute shell commands.
We packaged the audit as agent skills: infra-readiness-audit for the repo layer and live-infra-audit for the live layer. They are Apache licensed, they contain the exact commands and the priority model, and they run on any agent that can execute shell commands. Copy them into your agent's skills directory, point them at your own stack, and read the report before you decide whether you need to hire anyone. The repository is github.com/roqy-io/roqy-audit. If the report scares you, that was the point. If it is clean, you just bought certainty for zero dollars.

What coverage looks like in practice

A startup without a DevOps hire that runs this audit weekly gets: a list of every public port with a judgment on whether it should be public, TLS expiry tracked before it becomes an outage, backup directories verified by content, and SSH drift caught the week cloud-init introduces it.
A startup without a DevOps hire that runs this audit weekly gets: a list of every public port with a judgment on whether it should be public, TLS expiry tracked before it becomes an outage, backup directories verified by content, and SSH drift caught the week cloud-init introduces it. That is the difference between finding out about a problem from a customer and finding out from a report on Monday morning. The hire can come later. The coverage cannot wait.

5 Tips to Get Started

1

Run a read-only audit before you hire. Most first-audit findings are configuration, not architecture.

2

Verify backups by listing the output files, not by reading the cron line. A backup job can run daily and write nothing.

3

Check the reverse proxy's own admin port. It is the most commonly forgotten public surface on a small stack.

4

Give the auditor a read-only identity, never your admin credentials. If the auditor cannot write, it cannot break.

5

Re-run the audit weekly. Drift is the enemy, not the initial misconfiguration.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Sources & References

roqy.io cites authoritative sources including engineering blogs, vendor documentation, industry surveys, and academic research to ensure accuracy.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data and cited sources above.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

Can an AI agent really audit infrastructure safely?

Yes, if it is read-only by construction. Our audit skills run docker ps, ss, curl HEAD requests, and cloud list calls. They cannot restart, delete, or reconfigure anything. The worst case of a bad audit run is a report, not an outage.

What does the audit actually find?

On our own stack: an admin panel exposed on a public port, backup directories that were empty despite the cron running, a container without a restart policy, and SSH config drift from cloud-init overrides. All configuration-level, all fixable in an afternoon.

Is this a replacement for a DevOps engineer?

No. It is a replacement for having nothing. The audit tells you what is wrong and what the smallest fix is. Someone still has to apply the fixes. That someone can be a fractional DevOps engineer, a contractor, or your senior developer with a clear list.

How do I give an agent access without risk?

Create a dedicated read-only identity. On AWS that is an IAM user with only list, get, and describe permissions. On a VPS it is a system user that can run docker ps and read logs but has no sudo. Send the credentials, never your personal admin login.

How often should the audit run?

Weekly for the live checks (ports, TLS dates, backup freshness, disk). Monthly for the repo checks (secrets in git, CI gates, Terraform state). After every deploy of new infrastructure, run it once manually.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works