← Articles

April 4, 2026 · Tim Fraser, Cloud Operations Lead

One-Person DevOps: Running Production AWS When You're the Only One

You're the CTO, the only backend engineer, or the developer who happened to set up the AWS account. Whatever the title, the situation is the same: production runs on AWS, and you're the only person who understands it.

This is completely normal at startups with fewer than 20 people. It's also one of the most stressful positions in tech — because when something breaks at 2am, there's no one to escalate to.

Here's how to make it sustainable.

Accept the constraints

You cannot build a Netflix-grade infrastructure with one person. Don't try. Your goal is not perfection — it's a production environment that is reliable enough, secure enough, and maintainable enough that you can sleep at night and still build product during the day.

That means making deliberate choices about what you will and won't do:

This isn't cutting corners. It's prioritising correctly for your stage.

Automate deployments first

If you do nothing else, automate your deployments. A git push to main should result in your application being deployed to production without you clicking anything in the console.

This matters more than monitoring, more than security hardening, more than cost optimisation. Here's why: manual deployments are the single largest source of stress, errors, and wasted time for a solo ops person. Every manual step is a step you might forget on a Friday afternoon when you're tired.

GitHub Actions, GitLab CI, or even a simple CodePipeline — the tool doesn't matter much. What matters is that deploying is boring and repeatable.

Set up the minimum viable monitoring

You don't need Datadog, Grafana, and PagerDuty. You need:

These four things will catch 80% of production incidents. Set them up to notify you via email or Slack. You can add fancier monitoring later.

Build a runbook, even a short one

Write down the answers to these questions in a doc that someone else could follow:

This isn't documentation for documentation's sake. This is your insurance policy for the day you're sick, on holiday, or hiring your replacement. It's also incredibly useful at 2am when your brain isn't working properly.

Don't burn out

Solo ops is sustainable if you set boundaries. Some practical ones:

Batch infrastructure work. Don't context-switch between product development and operations all day. Pick one morning a week for ops tasks — security updates, cost review, dependency upgrades — and protect that time. Say no to complexity. Every new AWS service you add is a service you need to understand, monitor, and troubleshoot alone. Kubernetes is powerful, but if your ECS setup works, it works. Microservices are elegant, but a monolith you can deploy in one step is operationally simpler than 8 services you need to deploy in the right order. Use managed services for the hard stuff. RDS over self-managed PostgreSQL on EC2. SES over running your own mail server. Let AWS handle the boring operational work so you can focus on what makes your product different. Know when to get help. If you're spending more than 30% of your time on operations, something needs to change. That might mean hiring, or it might mean simplifying your architecture, or it might mean using tools that reduce the operational load.

The problem with being the only one

The hardest part of solo ops isn't the technical work. It's that there's no one reviewing your decisions, no one catching your mistakes, and no one noticing the thing you forgot to check.

You can be disciplined about security, diligent about cost reviews, rigorous about backups — but you're still one person. Things slip through. The security group someone asked you to open "temporarily" six months ago. The test database that's still running. The S3 bucket with overly permissive ACLs.

How plainfra acts as your second pair of eyes

This is where plainfra fits into a one-person ops setup. It connects to your AWS account with read-only access and does the review work that a second team member would do.

Ask it questions when you're troubleshooting: "Why is my RDS CPU high?", "What security groups allow inbound from 0.0.0.0/0?", "Which EC2 instances haven't been used in the last week?" It makes the API calls, reads the results, and gives you the answer.

But the weekly health report is where it really earns its keep for solo operators. Every week, plainfra scans all your connected AWS accounts and sends you a prioritised report covering security, cost, and operational health. It catches the things that slip through the cracks when you're heads-down building product.

It's a second pair of eyes that never takes a day off. You don't need to remember to audit your security groups, review your costs, or check for idle resources. The report does it for you. When everything is fine, it's a quick skim and you move on with your day. When something needs attention — a new public-facing resource, a cost anomaly, an expiring certificate — it's right there.

For a solo ops person, that weekly email is the difference between being reactive (scrambling when something breaks) and being proactive (fixing things before they become incidents). Stay subscribed so that when something goes wrong, you're not starting from zero trying to understand your own infrastructure.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.