What does Day 1 startup infrastructure actually cost?

Under 100 dollars a month if you are disciplined, and often well under 50. One container, one managed Postgres, GitHub Actions on Linux runners, crash reporting on a free tier. The bills that shock founders are almost never compute. They are the hourly charges on things that exist without doing work: NAT gateways at roughly 32 a month each, an EKS control plane at about 73, load balancers idling.

Do we need Kubernetes for our MVP?

Almost certainly not, and there is a clean test. If you cannot name the specific problem Kubernetes solves for you this week, you are buying an option rather than a solution. The control plane alone runs about 73 dollars a month per cluster before a single node exists. Run a container on a platform that manages it for you, and revisit the question when orchestration has become someone's actual job.

How do we stop GitHub Actions getting expensive?

A few habits cover nearly all of it. Stay on Linux, because Windows runners bill at double and macOS at ten times. Add a concurrency group so five pushes to one pull request do not bill as five complete pipelines. Cache your dependencies. Set a job timeout so a hung process cannot quietly bill you overnight. None of that takes an afternoon to implement.

Should we start on AWS or something simpler?

Simpler, until you have a reason not to be. AWS is not costly because compute is costly. It is costly because it charges hourly for correctness you have not needed yet, and it is unforgiving toward teams without a specialist. Fly, Railway or Render will run a container and a database for the price of lunch. Move when a customer requires it or a bill justifies it.

What is the minimum monitoring we can get away with?

Crash reporting, live before your first user. If an exception reaches production you should learn about it from a stack trace with a line number, not from a customer email written in capitals. That is a free tier and twenty minutes of setup. Metrics dashboards and Prometheus can wait for an outage worth investigating, because a dashboard nobody opens is a subscription to a feeling of control.

We inherited a huge Terraform setup. Should we tear it down?

Not on principle, and not in one go. Work out what it costs monthly and which parts are load-bearing. NAT gateways, idle clusters and duplicated non-production environments are usually most of the bill and almost none of the value. Delete those first, keep whatever is genuinely holding the product up, and do it one resource at a time with the invoice open beside you.

The Day-One Infrastructure Tax: Setting Up DevOps Without Killing Startup Runway

/KEY TAKEAWAYS

The short version

01Day 1 infrastructure is a checklist, not a platform. If it takes longer than a day to stand up, someone is selling you a problem you do not have yet.
02A NAT gateway costs roughly 32 dollars a month purely to exist, before a byte crosses it. Run one per availability zone as the high-availability advice says, and that is near 97 a month in hourly charges alone.
03An EKS control plane is about 73 dollars a month per cluster before a single pod runs. Most pre-revenue startups are paying for an option, not a solution.
04CI/CD is close to free until you make it expensive. On GitHub Actions, Windows runners bill at double the Linux rate and macOS runners at ten times.
05Monitoring nobody reads is a subscription to a feeling. Wire up crash reporting before your first user and skip the dashboards until something has actually broken.

Nobody budgets for the infrastructure tax, because it is not a line item. It is a hundred small ones.

You did not sit down and decide to spend 400 dollars a month before your first customer existed. You made eleven reasonable decisions in a row, every one of them defensible in isolation, and the invoice is simply the sum of them.

So here is what Day 1 genuinely needs.

What does a complete startup infrastructure checklist look like on Day 1?

Shorter than you have been led to believe. You can have all of it standing before lunch.

Source control with a protected main branch. Nobody pushes directly to it. Not you, not at 2am, not just this once.
One pipeline that runs your tests and refuses the merge when they fail.
One Dockerfile, so the thing running on your laptop is the thing running in production.
One managed Postgres. Not a cluster. Not a self-hosted instance whose backups are now your personal responsibility.
One deploy command any engineer can run, and that same command with a flag to roll it back.
Crash reporting, wired in before your first user, so you hear about exceptions from a stack trace rather than from a tweet.

That is the list. The interesting part is what is missing from it.

No Kubernetes. No service mesh. No Terraform module hierarchy inherited from a company with two hundred engineers. No staging environment that is a slightly worse copy of production which nobody quite trusts. Every one of those is a real tool with real reasons to exist, and not one of those reasons applies to you in week one.

Isometric schematic of a linear assembly line of abstract gates and a test chamber with one branch looping back to the start — A handful of stations and one loop back to the start. That is the entire pipeline. Almost everything marketed to you as DevOps is this diagram with more vendors bolted onto it.

How do you implement CI/CD pipelines and monitoring on AWS without racking up massive bills?

By knowing which meter is running. Most of them run whether or not you are using the thing.

CI/CD is the easy half. GitHub Actions bills by the minute against a free monthly allowance on private repositories, and an ordinary test suite for an ordinary startup will not exhaust it. Teams blow through it by ignoring the multipliers. Linux minutes bill at the base rate. Windows runners bill at double. macOS runners bill at ten times. Put an iOS build on a macOS runner, fire it on every commit to every branch, and you will meet this fact at the end of the month.

Cache your dependencies. Stay on Linux unless you physically cannot. Stop running the full suite on every push to every branch.

Monitoring is where discipline actually earns its keep, because CloudWatch charges per gigabyte ingested and your application is thrilled to produce gigabytes. Log what a human will read. Sample the rest. An observability bill that exceeds your compute bill is not sophistication, it is debug logging somebody left switched on in March.

.github/workflows/ci.ymlyaml

name: CI

on:
  pull_request:          # not every push to every branch
  push:
    branches: [main]

# A new push to the same PR kills the run already in flight.
# This block alone is the difference between a free tier and an invoice.
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest   # 1x multiplier. macos-latest bills at 10x.
    timeout-minutes: 10      # a hung job cannot bill you all night

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm         # skip a cold install on every single run

      - run: npm ci
      - run: npm run test -- --run
      - run: npx tsc --noEmit

      # Migrations run against a real Postgres, not a mock.
      # Catching a bad migration here costs 40 seconds.
      # Catching it in production costs your Saturday.
      - run: npm run db:migrate

The concurrency group and the timeout are doing more for your bill than any dashboard will. Neither one needed a platform team to write.

Which line items actually kill runway?

Not the ones you watch. The ones that bill hourly for the privilege of existing.

The NAT gateway is the classic. Around 32 dollars a month to exist, plus a per-gigabyte charge on everything passing through, multiplied by however many availability zones your high-availability diagram acquired. It performs no work. It is a toll booth on a road you built.

The EKS control plane is about 73 dollars a month per cluster, before you have run one pod or paid for one node. Keep a staging cluster alongside it and that is 146 a month to operate an orchestrator for a service with forty users.

CloudWatch bills per gigabyte ingested, and your debug logging is generous by nature. An idle Application Load Balancer bills by the hour whether anyone visits or not. Cross-availability-zone data transfer bills in both directions, quietly, forever, in amounts too small to notice individually.

None of these appear in a proposal. All of them appear on the invoice.

A wall-mounted bank of dozens of identical analogue utility meters receding into a dim plant room — Every one of these is spinning. Not one of them is doing work. This is what a well-architected cloud diagram costs while your product has forty users.

/TRADE-OFFS

Day 1 minimum vs the platform you were sold

The right column is not wrong. It is correct for a company you are not yet, and every row of it bills monthly while you find out whether you will be.

Criterion	Day 1 minimum	The proper platform
Compute	One container on Fly, Railway or a small ECS service. Roughly 20 a month.	EKS. About 73 a month for the control plane alone, before any node exists.
Database	Managed Postgres. Neon or RDS. Backups are somebody else's job.	Self-hosted Postgres with a replica you personally maintain at 2am.
Networking	Public subnet, a security group, done. No NAT gateway.	Private subnets with a NAT per AZ. Near 97 a month just to exist.
CI/CD	One GitHub Actions workflow on Linux runners. Near zero.	Self-hosted runners on EC2 that you now patch yourself.
Infrastructure as code	A README listing what to click. Honest, sufficient, and read by everyone.	A Terraform module hierarchy copied from a 200-engineer company.
Monitoring	Sentry free tier. You read every alert, because there are very few.	Prometheus, Grafana, and alerts nobody has acknowledged since March.
Time to stand up	One day.	Three weeks, and probably a hire.
When it is the right call	Zero through to your first serious customer.	Once you have compliance obligations, real scale, or someone whose job is to own it.

When does this stop being enough?

Later than the anxiety suggests. And there are real signals for it, rather than vibes.

You need private networking once you hold data that legally cannot sit on a public subnet, and not one day before. You need Kubernetes once you have enough services that orchestrating them by hand has quietly become somebody's full-time job, which is a problem you will feel long before you can name it. You need Terraform once more than one person changes infrastructure and you have been surprised by a change you did not make.

You need real monitoring the first time something breaks and you cannot say why.

Every one of those is a consequence rather than a prediction. Each arrives carrying its own evidence. Build for the evidence.

The startups that die of infrastructure are rarely the ones that under-built. They are the ones that spent six weeks building for a scale they never reached, on the recommendation of a conference talk given by a company with a thousand times their traffic and a platform team to match.

/FAQ

Questions technical founders actually ask

What does Day 1 startup infrastructure actually cost?: Under 100 dollars a month if you are disciplined, and often well under 50. One container, one managed Postgres, GitHub Actions on Linux runners, crash reporting on a free tier. The bills that shock founders are almost never compute. They are the hourly charges on things that exist without doing work: NAT gateways at roughly 32 a month each, an EKS control plane at about 73, load balancers idling.
Do we need Kubernetes for our MVP?: Almost certainly not, and there is a clean test. If you cannot name the specific problem Kubernetes solves for you this week, you are buying an option rather than a solution. The control plane alone runs about 73 dollars a month per cluster before a single node exists. Run a container on a platform that manages it for you, and revisit the question when orchestration has become someone's actual job.
How do we stop GitHub Actions getting expensive?: A few habits cover nearly all of it. Stay on Linux, because Windows runners bill at double and macOS at ten times. Add a concurrency group so five pushes to one pull request do not bill as five complete pipelines. Cache your dependencies. Set a job timeout so a hung process cannot quietly bill you overnight. None of that takes an afternoon to implement.
Should we start on AWS or something simpler?: Simpler, until you have a reason not to be. AWS is not costly because compute is costly. It is costly because it charges hourly for correctness you have not needed yet, and it is unforgiving toward teams without a specialist. Fly, Railway or Render will run a container and a database for the price of lunch. Move when a customer requires it or a bill justifies it.
What is the minimum monitoring we can get away with?: Crash reporting, live before your first user. If an exception reaches production you should learn about it from a stack trace with a line number, not from a customer email written in capitals. That is a free tier and twenty minutes of setup. Metrics dashboards and Prometheus can wait for an outage worth investigating, because a dashboard nobody opens is a subscription to a feeling of control.
We inherited a huge Terraform setup. Should we tear it down?: Not on principle, and not in one go. Work out what it costs monthly and which parts are load-bearing. NAT gateways, idle clusters and duplicated non-production environments are usually most of the bill and almost none of the value. Delete those first, keep whatever is genuinely holding the product up, and do it one resource at a time with the invoice open beside you.

DeltaCodes