DevOps That Actually Fits Small Teams

DevOps culture has a marketing problem. The conference circuit is dominated by Netflix, Google, and Spotify war stories that are completely inapplicable to a team of four engineers shipping a B2B SaaS product.

This post is about practical DevOps for teams of 1–10 engineers. No platform engineering department required.

The core problems DevOps solves

Before adding any tooling, be clear about what you are actually trying to fix:

1. Slow feedback loops — developers wait hours to find out if their change broke something
2. Unreliable deployments — Friday deployments are terrifying
3. Knowledge silos — only one person knows how to deploy
4. Environment drift — “it works on my machine” is still a real problem

Solve these four problems and you have most of what DevOps promises.

A minimal viable DevOps stack

For a small team, we recommend starting here:

CI: GitHub Actions

GitHub Actions is free for public repos and very affordable for private ones. It integrates perfectly with your existing GitHub workflow and requires no separate system to maintain.

A good starting pipeline:

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm test
      - run: npm run build

That is it. Run tests on every push, block merges if they fail.

Infrastructure: Terraform or Pulumi

Pick one and be consistent. Terraform has more tutorials; Pulumi lets you write infrastructure in TypeScript. Either is fine.

The goal is that your infrastructure lives in source control, is reviewed like code, and can be recreated from scratch in under an hour.

Secrets: Never in source control

Use environment variables injected at runtime. In GitHub Actions, use repository secrets. In production, use your cloud provider’s secret manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).

Observability: Start with structured logs

Before adding Prometheus, Grafana, and distributed tracing, make sure your application logs structured JSON. Then ship those logs to a managed service (Datadog, Better Uptime, or even Cloudflare Workers Analytics Engine).

You can answer 90% of production questions with good logs.

What to skip

• Kubernetes — not until you have multiple services that genuinely need independent scaling
• Service mesh — not until you have Kubernetes
• Microservices — not until you have a modular monolith that is actually hurting you
• Complex GitOps flows — not until you have multiple deployment environments with real governance requirements

Conclusion

Good DevOps for a small team is boring. It is a git push that triggers tests, a merge that triggers a deployment, and logs that tell you what went wrong.

Build that first. Everything else comes later.