DevOps for startups: what to set up at each stage, and what to skip.

Do the minimum that keeps the next stage cheap.

DevOps for startups isn't a smaller version of what a bank does. It's a series of bets about which problems will hurt soon and which won't. Get it wrong one way and you spend months on a platform nobody needs. Get it wrong the other way and a deleted database or a leaked key costs you a customer.

One test works at every stage: will this be much harder to do later? Single sign-on, separate AWS accounts and tested backups get more painful every month you wait. Kubernetes, service meshes and multi-region setups don't. They can be added when there's a reason, and usually there isn't one.

So the list below is short on purpose. Each stage adds a few things, and names the things you should skip even though a blog post told you not to.

Pre-seed and prototype: protect the account, then ship.

At this stage you have no customers to protect, only a bank card and some code. Your DevOps work should take an afternoon, not a sprint. If the prototype came out of Lovable, Replit or Bolt, our guide to taking a vibe-coded app to production covers what to fix before customers arrive.

• Lock the root user. Turn on MFA, remove any root access keys and stop using root for daily work.
• Create the account inside an AWS Organization, even with one account. Organizations is offered at no additional charge, and it makes the split you'll want at seed a small job instead of a migration.
• Set a budget alert. Monitoring and notifications in AWS Budgets are free. A forgotten GPU instance or a runaway log group is the most common way a prototype burns real money.
• Deploy one way, every time. A script in the repo, ECS Express Mode or Fargate, or a PaaS. What matters is that it isn't a person clicking in the console.

Skip Terraform for every resource, a staging environment and anything with "cluster" in the name. If you've applied for credits (AWS Activate offers up to $5,000 self-funded, and up to $200,000 through an approved provider), treat them as runway, not as permission to over-build. Our credits runway calculator shows when they run out at your current burn.

Seed, with first customers: make production boring.

Paying customers change the question from "does it work?" to "what happens when it breaks?". This is the stage where a few days of setup saves the most pain later.

• Separate production. Put prod in its own AWS account and keep experiments elsewhere. A mistake in dev then can't delete customer data.
• Single sign-on for AWS. IAM Identity Center is offered at no extra charge. Give people roles, not long-lived access keys, and offboarding becomes one click.
• Deploys from CI. Merge to main, tests run, the build ships. GitHub Actions includes 2,000 free minutes a month for private repos on the Free plan and 3,000 on Team, which covers most seed teams. Past that, see GitHub Actions pricing in 2026. Not on GitHub, or not sure you should be? CI/CD tools for startups compared.
• A managed database with real backups. RDS keeps automated backups for up to 35 days. The console default is seven, the API default is one. Check yours, then restore a backup into a scratch instance once so you know it works and how long it takes.
• Know when it's down before customers do. An external uptime check on the main endpoint and error tracking in the app (what Sentry costs at this size). That's enough monitoring for now.

Skip multi-region, a service mesh and the platform team you'll read about. If you're choosing a container platform now, our ECS vs EKS guide explains why ECS on Fargate is the usual answer below 15 engineers. For the wider AWS setup, see AWS for startups.

Post-seed growth: write it down, in code and in plain English.

Now there are more engineers, more services and more ways to break each other's work. The goal shifts from "it runs" to "anyone on the team can change it safely".

• Infrastructure as code for production. Terraform or OpenTofu, CDK if your team prefers TypeScript. Start with prod networking, the database and the services. Changes go through pull requests like application code.
• A staging environment that's built from the same code as prod, smaller and cheaper. One shared staging is enough. Per-branch preview environments are nice and rarely worth the cost yet.
• Alerts that page a person. A handful of alarms on what customers feel: error rate, latency, queue depth, database storage. The CloudWatch free tier covers 10 standard alarm metrics, which is roughly the right number to start with.
• An incident routine. Who gets paged, where you talk, how you write up what happened. One page in the wiki is plenty.
• Cost tags and an anomaly alert. Tag resources by service and environment. AWS Cost Anomaly Detection runs about three times a day and can take up to 24 hours to flag an unusual spike, so pair it with a budget alert. More in AWS costs for startups.

This stage is where infrastructure starts taking a day a week from a senior engineer. That's the signal to decide who owns it, which section 08 covers.

Series A prep: prove it's under control.

Investors' technical due diligence and larger customers' security questionnaires ask the same things: who has access, what's logged, how you recover, and whether anyone owns it. You want true, boring answers.

• Audit logs on. CloudTrail across all accounts, sent to a bucket in an account most people can't touch.
• Least privilege, reviewed. Remove the admin roles people collected along the way. Keep a short list of who can reach production and why.
• Restore and rollback, documented and tested. Write down the steps and the last date you ran them.
• A security baseline. GuardDuty or similar, encryption at rest, no public buckets by accident, dependencies scanned in CI.
• SOC 2 groundwork, if enterprise buyers are asking for it. Most of the controls are things on this page you should already have.

Skip the rewrite. A diligence reviewer is more impressed by a simple setup that's documented than a complex one that only one person understands. Our production readiness checklist is a good self-review before anyone else does it.

Who does the work: in-house, fractional or managed.

There are three honest ways to cover DevOps at a startup, and most companies use more than one over time.

Your own engineers. Right at pre-seed and often at seed, when the work is a few hours a week and the CTO knows the system best. It stops working when infrastructure quietly takes a day a week from your most senior person, because that day comes out of product.

Fractional help. A part-time senior engineer, or a small team, who does the projects on this page and then keeps them in shape. It fits seed and post-seed, when the work is real but not a full-time job. See fractional DevOps for how ours works.

Managed operations. Someone else watches production, patches and answers alerts, and you direct less of the work. It fits teams who want prod looked after rather than hours to spend. See managed DevOps on AWS.

A full-time hire. Right when infrastructure fills a full week, every week, or when infrastructure is your product. We've written up the signals, 2026 pay data and the year-one cost comparison in when to hire your first DevOps engineer, so we won't repeat it here. The short version: count the hours infrastructure took from your team over the last eight weeks, and let that number decide.

"Buy" also applies to tools. At every stage, prefer a managed service you pay for over one you run yourself, unless you have a specific reason. A managed database, hosted CI and a hosted error tracker cost less than the engineer time to run your own. Our APM tools comparison prices hosted and self-hosted monitoring side by side.

Mistakes we'd steer you away from.

1. Building for Series C at pre-seed. Kubernetes, multi-region and a service mesh for an app with 40 users. The cost isn't the AWS bill, it's every hour spent keeping it running instead of shipping.
2. Everything in one AWS account. Dev, prod and the founder's experiments side by side, so one wrong command reaches customer data. Splitting later means moving live resources.
3. Backups nobody has restored. A backup you've never restored is a hope. Restore once at seed, and on a schedule after that.
4. Access keys on laptops. Long-lived keys outlive the people who made them. SSO with short-lived credentials fixes this for free.
5. Alerts that page for everything. If the team ignores alerts, you have no alerts. Page only for what customers feel, and send the rest to a channel.
6. Nobody owns the bill. Credits hide waste until the month they run out. Give the bill an owner and a monthly look long before then.
7. The one person who knows. Infrastructure that lives in one engineer's head becomes a crisis the week they leave. Code and a short runbook are the cure, whoever does the work.