The DevOps Minimum for a 5-Person AI Startup

The "DevOps minimum" mindset

Five people. One to three of them are engineers. You are almost certainly not one of those engineers — or if you are, you're also writing features, talking to customers, and figuring out GTM. Nobody has time to become an SRE.

But you also can't afford the three outages that will happen if you do nothing. Two of them will hit on Friday evenings. One will take down your demo right before a Series A call.

The DevOps minimum isn't "build a robust platform." It's a much simpler goal: prevent the three most common, completely preventable outages that kill early AI startups. Secrets committed to git. No uptime alerting. A GPU inference job taking down your main API. The minimum stack exists to close those three holes and nothing else.

Every decision below is about trading money for simplicity, and simplicity for engineer sleep. If you can't explain why a tool is there in one sentence, don't add it yet.

Hosting

For most early-stage AI startups, there are three distinct layers of infrastructure, and you should treat them separately.

Marketing and frontend product: Vercel. If you're running Next.js — and you probably are — Vercel is essentially zero-config deployment. Preview environments on every PR, edge CDN, automatic HTTPS, excellent DX. The cost is real at scale but irrelevant at five people. Don't overthink this.

Full-stack apps with state: Render or Railway. When you need background workers, persistent databases, or workloads that don't fit the serverless model, these give you most of what you'd get from AWS without the AWS tax on your time. Render's managed Postgres is fine until you're handling millions of rows. Railway has slightly better DX. Pick one, don't switch until it hurts.

AI inference: Decouple it completely. This is the part most startups get wrong. Your GPU-backed inference — anything calling Replicate, RunPod, or Modal — should not share a deploy boundary with your web application. When an inference job OOMs at 2 AM, you want your main app to stay up. RunPod is good for persistent GPU capacity. Modal is excellent for bursty serverless GPU workloads where you're calling Python functions directly. Replicate wraps open-source models with a simple REST API and handles cold starts for you. Use the managed options first. Don't provision your own GPU instances until you have strong reasons about cost or control.

After Series A: SST on AWS or CDK directly if you have someone who knows AWS. Not before.

CI/CD

The shortest viable GitHub Actions setup takes about 30 minutes and prevents 80% of the regressions that make it to production. Here's the structure:

on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck
      - run: pnpm test --passWithNoTests

On PR open, this runs automatically. Vercel and Render both watch the same repo and spin up a preview environment. You get a URL to share with stakeholders without any extra work. On merge to main, trigger a production deploy manually (or auto-deploy — your call, but manual-trigger is safer early on because you're still doing a lot of fast iteration).

Do not build a complex multi-stage pipeline right now. Do not add matrix builds, canary deploys, or blue-green unless you have a specific outage that would have been prevented by them. Add the smallest thing that fixes the next real problem.

Observability

You need three things and only three things at this stage.

Error tracking: Sentry. Install it in your frontend and your API. Set up Slack notifications for new error types. The free tier is fine for early-stage. The goal is that you find out about errors before your users file support tickets.

Uptime monitoring: Better Uptime or Checkly. Pick one. Set up checks on your key URLs — your homepage, your API health endpoint, your auth flow. Both services will page you via Slack or SMS when something goes down. Better Uptime is simpler. Checkly gives you synthetic browser tests if you need to check that a login flow actually works end-to-end. Set the alert threshold at 2 consecutive failures to avoid noise from transient blips.

LLM tracing: This is the one most teams skip and then regret. Langfuse, Helicone, or Braintrust all do roughly the same thing: log every LLM call with its input, output, latency, token count, and cost. Without this, you cannot answer the following questions that you will definitely be asked: why did the agent fail on this input? why did our API bill double this week? what's our median latency per user? Langfuse is open-source and self-hostable if data residency matters to you. Helicone is the simplest to wire in — it's a proxy, so you swap one base URL and you're done. Braintrust goes deeper on evals if that's a priority. Start with Helicone if you just want observability fast.

Secrets and IAM

The rule is simple: don't roll your own secrets management. A .env file in a shared Notion doc has already cost some startup you know a six-figure incident.

The options that actually work: Doppler for teams that want a dedicated secrets manager with per-environment isolation and a good CLI. 1Password Secrets for teams already using 1Password for credentials — the developer tooling is solid and the audit log is there. AWS Secrets Manager if you're already deep in AWS and want everything in one place.

Whatever you pick, enforce three things from day one. First: per-environment isolation. Your dev credentials cannot touch prod data. Staging must be a separate environment with its own API keys. Second: per-engineer access boundaries. Not everyone needs prod database credentials. IAM is not about trust, it's about blast radius. Third: an audit log on all secret reads. When something leaks — and it will leak, because someone will accidentally paste a key into Slack or commit a .env.production file — you need to know which key was exposed and when.

AI-specific note: your LLM provider API keys (OpenAI, Anthropic, whatever you're using) must rotate easily. Budget for it from the start. Set your secrets manager up so that rotating a key is a two-minute operation, not a two-hour one. You will leak a key at some point. The only question is how painful the rotation is.

The on-call setup that doesn't kill morale

At five people, an on-call rotation that pages people constantly is a retention problem within three months. Before you set up any alerting, decide what constitutes a customer-impacting outage. Write it down.

A customer-impacting outage is: your uptime check fails for two consecutive intervals; your error rate spikes above a threshold you define (5% is a reasonable starting point); your payment processing fails. That's it.

Not a customer-impacting outage: a staging environment error; a single-user issue that isn't reproducible; a log warning that your LLM responded in 4 seconds instead of 2; a flaky test in CI.

The on-call rotation should be one or two engineers per week, maximum. If you only have two engineers, you're alternating weekly. PagerDuty handles scheduling, escalation policies, and on-call handoffs cleanly — it's worth the cost if reliability matters. If you're comfortable with a slightly simpler setup, Slack alerts with a manual escalation path (ping the other engineer directly) works fine for a 2-person rotation.

The goal is that an on-call week costs each engineer one interrupted night per quarter, not one interrupted night per week. If it's the latter, your alerting is misconfigured.

When to graduate from "minimum" to "real"

The minimum stack is not permanent. Here are the signals that you've outgrown it.

You've had two or more production outages in a single quarter that the minimum stack didn't catch. You're past 12 engineers and the ad-hoc on-call setup has become a negotiation every Monday. SOC 2 requirements are arriving from enterprise customers — at that point you need a proper access control framework, not Doppler and good intentions. You have compliance or data-residency requirements that demand multi-region deployments. People are quietly mentioning on-call as a reason to look elsewhere.

When those signals show up, the right move is usually to hire one platform or infrastructure engineer, not to add more tools. One person with a clear mandate to build the internal platform is worth more than a committee of five product engineers picking up Terraform on weekends.

Until then, resist the urge to build what you don't yet need. Every hour spent architecting a zero-downtime deployment pipeline is an hour not spent talking to customers.

---

The goal of DevOps at a 5-person AI startup is not to build a platform. It is to not get woken up by a preventable outage on a Friday night. The stack described here — managed hosting, a 30-minute CI pipeline, Sentry plus an uptime checker plus LLM tracing, Doppler or 1Password for secrets, and a tightly scoped on-call rotation — gets you there in under a week of setup time. It leaves your engineers free to build product while keeping the preventable disasters preventable. If you're building with AI and want a team that's already thought through where hiring fits into this picture, Reveronix works with AI-native startups at exactly this stage of the infrastructure curve.