↓ Skip to main content
Oh My Ops | DevOps Guides, stacks & tools for engineers

Minimal DevOps Stack for a Small Startup

·1721 words·9 mins
Author
Maksim P.
DevOps Engineer / SRE
Table of Contents

TL;DR
#

For a 3–5 person startup, the best “DevOps stack” is the one you can maintain. Pick one git host + one CI/CD, prefer managed services, run staging + prod, and keep observability to a small set of high-signal metrics, logs, and alerts.

Who this guide is for
#

This guide is for small engineering teams of about 3–5 people working on a SaaS or web product. You don’t have a full-time DevOps/SRE, but you still want sane deployments, basic reliability, and not to burn weekends on infrastructure. The goal is a minimal stack you can set up in days and maintain with a fraction of one engineer’s time.

If your team is bigger than ~10 people or you have strict compliance requirements, use this as a starting point—not the final form.

Principles of a minimal stack
#

Before picking tools, it’s useful to set a few principles:

  • Less is more. Fewer moving parts beat a “modern” stack you can’t support.
  • Managed over self-hosted. Use managed services wherever they don’t destroy your budget.
  • One tool per problem. One place for code, one CI/CD, one primary cloud, one monitoring stack, one log sink, one secrets store.
  • Everything-as-code where it’s cheap. CI pipelines, core infra config, and critical alerts should be versioned—but don’t turn everything into an IaC museum.
  • Easy to hand over. Any senior engineer on the team should be able to understand the setup in a day.

Core components
#

1. Source control & reviews
#

You need:

  • Git hosting (GitHub / GitLab / Bitbucket—pick one and stick to it).
  • Protected main branch, required reviews, required status checks from CI.
  • A simple branch model: main + short-lived feature branches.

Minimal process:

  1. Feature branch → PR/MR.
  2. CI runs tests + basic checks.
  3. At least one review from another developer.
  4. Merge only when CI is green.

2. CI/CD for small teams
#

For a small startup, native CI from your git host is usually enough:

  • GitHub → GitHub Actions
  • GitLab → GitLab CI
  • Bitbucket → Bitbucket Pipelines

Minimal pipeline:

  • On PRs:
    • install dependencies, run tests, linters, and basic security checks
  • On merge to main:
    • build an artifact/container image
    • deploy to staging automatically
    • run smoke tests
  • Deploy to prod:
    • a manual approval step (button/job) with clear visibility into what’s shipping

Key ideas:

  • One pipeline definition per service, stored in the repo.
  • The same pipeline for staging and prod—only environment variables and parameters differ.
  • Rollbacks must be easy: either deploy the previous image or have a “promote previous release” step.

3. Runtime & hosting
#

For 3–5 engineers, you usually do not need to run your own Kubernetes zoo.

Reasonable options:

  • App Platform / PaaS (managed containers / app service): minimal ops, fast start.
  • Or a single managed Kubernetes cluster, only if:
    • you have multiple services,
    • you need more control over networking/add-ons,
    • you already have production Kubernetes experience on the team.

If you’re building a fast MVP, you can also run something lightweight (for example, k3s) on a single node—but treat it as a stepping stone, not your forever platform.

Minimal requirements:

  • One primary runtime (not three).
  • A clear deployment path via CI (kubectl/helm/PaaS CLI), not “someone clicks deploy from an IDE”.
  • One environment per stage: staging and prod.

4. Databases & storage
#

Don’t reinvent the wheel:

  • Primary DB: managed Postgres/MySQL in your cloud (model costs early).
  • Migrations: a migration tool run as a discrete step in the pipeline, before the new version rolls out — never from the app’s entrypoint.
  • Object storage: managed S3-compatible storage for files and backups.

Rules:

  • Backups must exist from day one, and restoration should be tested at least once.
  • Access the DB via scoped users/roles, not root everywhere.

Why migrations don’t belong in app startup. It is a tempting shortcut — one less pipeline step, and the schema is always up to date. It works fine on one replica and breaks the moment you have two. Both pods boot at the same time and run the same DDL concurrently: you get lock contention at best, a half-applied migration at worst, and it fails intermittently, which is the worst kind of failure to debug. Rolling updates make it worse — during the rollout, old and new pods serve traffic against whichever schema won, so the old code can be talking to a table that no longer has the column it selects.

Do it as its own step instead: a pipeline job (or a Kubernetes Job, or an ECS one-off task) that runs to completion before the new version is deployed, with the deploy gated on its success. One runner, one migration, a clear failure if it doesn’t work. Then write migrations so both versions can survive the overlap: add columns before you write to them, stop reading a column in one release and drop it in the next, and don’t rename anything in a single step. That expand-then-contract habit costs nothing and is what makes zero-downtime deploys possible later.

5. Observability: logs, metrics, alerts
#

Goal: know when production is down or degraded, and be able to debug quickly—without spending months building an observability “platform”.

Minimal set:

  • Metrics:
    • basic service metrics (CPU, RAM, disk, request latency, error rate, RPS)
    • one metrics backend (hosted is usually fine)
  • Logs:
    • structured logs from apps (JSON is preferable)
    • one log sink with field search
  • Alerts:
    • a small, SLO-ish set:
      • service down / health checks failing,
      • error rate above threshold,
      • latency above threshold,
      • critical resource pressure (disk full, memory pressure).

Principle: 5 good alerts beat 50 ignored ones.

6. Security & access
#

Minimal, but not zero:

  • VPN / bastion / zero-trust access to private resources.
  • Secrets management:
    • no secrets in the repo,
    • one centralized secrets mechanism (managed secrets service or a simple, consistent approach).
  • MFA on your git host, cloud accounts, and admin consoles.
  • Least privilege:
    • developers don’t need full admin in production,
    • service accounts get only what they actually need.

Example minimal stack (opinionated)
#

Below is an example of a realistic minimal stack for a 3–5 person team:

  • Git hosting: GitHub or GitLab
  • CI/CD: native CI from the same provider
  • Cloud: one primary cloud provider, two environments (staging/prod)
  • Runtime: managed app platform or a single managed Kubernetes cluster
  • DB: managed Postgres/MySQL
  • Object storage: managed S3-compatible storage
  • Monitoring: one metrics backend
  • Logs: one log management backend
  • Secrets: one secrets manager
  • Access: VPN/zero-trust + MFA everywhere

The point is one shared stack for the whole team—not a different snowflake setup per service.

Environments & deployment flow
#

A minimal, working flow:

  1. Developer creates a feature branch, pushes, and opens a PR/MR.
  2. CI runs tests/linters; status is reported back into the PR.
  3. After review and green CI → merge to main.
  4. Auto-deploy to staging and run smoke tests.
  5. If staging is OK → manually trigger a deploy to prod.
  6. If something goes wrong:
    • roll back to the previous artifact/release in one step,
    • use logs/metrics to understand the failure.

Rule: any production deploy should be:

  • fast (minutes, not hours),
  • repeatable (no manual SSH “rituals”),
  • observable (you can see what was deployed and by whom).

Cost and maintenance checklist
#

When thinking about cost and effort, review:

  • Git + CI:

    • per-user pricing and CI minutes/runners,
    • whether you can use a startup plan/credits.

  • Cloud:

    • baseline staging + prod cost (compute),
    • managed DB cost, storage, traffic/egress,
    • how you can scale without a total rebuild.

  • Observability:

    • retention costs for logs/metrics,
    • ingestion limits that can create surprise bills.

  • Ops time:

    • who owns the stack,
    • how many hours/week you spend patching and firefighting,
    • whether you have a lightweight on-call rotation.

A healthy target for a 3–5 person team: keeping this stack running should take less than half of one engineer’s time.

When to move beyond this minimal stack
#

Sooner or later, a minimal stack becomes too small. Typical triggers:

  • team grows beyond ~10–15 engineers,
  • you end up with multiple independent products/services,
  • compliance requirements appear (SOC 2 / ISO 27001 / regulated industry),
  • load grows and you hit real limits or reliability issues.

At that stage teams usually:

  • expand observability (tracing, better SLOs, error tracking),
  • introduce stricter release processes (canaries, safer rollouts),
  • invest more in IaC (multi-account setups, network policy, DR),
  • hire dedicated DevOps/SRE or form a small platform function.

This guide is a starting point, not the final architecture.

Next steps
#

1. Apply this to your team
#

  • Map your current stack and mark where you have the most tool sprawl.
  • Compare with the principles above and simplify:
    • one git host,
    • one CI,
    • one primary cloud,
    • one monitoring backend,
    • one log sink,
    • one secrets manager.
  • Identify which 2–3 changes will give you the most benefit in the next month.

2. Explore ready-made stacks
#

This guide is deliberately tool-agnostic. If you’d rather start from working config than from principles, the Stacks section has the same ideas written out as copy-paste setups:

  • Startup CI/CD stack — GitHub Actions building Docker images, pushing to ECR, deploying to ECS Fargate. This is section 2 of this guide, made concrete.
  • Infrastructure as Code starter — Terraform for a VPC, ECS Fargate, RDS Postgres and S3, with a plan/apply pipeline. Covers sections 3 and 4.
  • Kubernetes monitoring stack — Prometheus, Grafana, Loki and AlertManager with Helm values, if you went the cluster route. Covers section 5.

Take one, not all three. The stack you can maintain beats the stack you copied in full.

3. Need help implementing this?
#

If you want to go beyond reading and quickly improve your stack:

  • Minimal Stack Review (90-minute call + written plan) Quick audit of your current setup and a concrete simplification plan.

  • MVP Infra Setup Set up a minimal stack for your product: CI/CD, environments, basic monitoring, and logs.

  • Cost & Reliability Checkup Light audit of cloud costs and risks (missing backups, access gaps, missing alerts).

→ If this is relevant, go to the Services page and leave a request.

Related reads #

Reply by Email