engineering· May 4, 2026· 9 min read

Why Your Infrastructure Setup Order Matters (And How to Get It Right)

Identity → substrate → services → integrations. A four-stage mental model for setting up infra in the right order, every time.

Why Your Infrastructure Setup Order Matters (And How to Get It Right)

"Do I buy the domain first or set up the server first?"

That question, in some form, is the single most common thing newcomers to ops ask. And it's usually answered with a tutorial that just lists steps in some order — leaving the asker to wonder whether the order is essential or arbitrary.

It's essential. Here's how to think about it so you don't have to memorise the order for every tool.

The core idea: outputs become inputs

Almost every infrastructure setup is a chain. Each step produces an output (a domain, an IP, a key, a token, a record) that becomes the input for a later step.

If you do steps out of order, you either:

  1. Block on yourself. You can't continue because the input doesn't exist yet.
  2. Have to redo work. You set something up with a placeholder, then come back and reconfigure it once the real value exists.
  3. Create silent failures. Things appear to work but actually don't (DNS propagation, auth scopes, IP allowlists).

Most setup-order mistakes fall into bucket 3, which is the worst because you discover them later, far from the original change.

The four-step mental model

Almost every infrastructure setup follows the same four-stage pattern. If you know which stage you're in, you know what depends on what.

Four-stage dependency diagram: Identity → Substrate → Services → Integrations

Each stage produces outputs that feed the next. Skip a stage and you discover it later, far from the original change.

Stage 1: Identity

Things that the world uses to find you. These have the longest lead time (DNS propagation, registrar verification, certificate authority checks) and almost everything else depends on them.

  • Domain registration
  • DNS records (A, AAAA, CNAME, MX, TXT)
  • Reverse DNS (PTR)
  • TLS certificates

Always do these first. They cost nothing to set up early and they prevent every kind of cascading delay later.

Stage 2: Substrate

The compute and storage that runs your stuff. Independent of identity except where Stage 1 needs to point at it (so you need an IP, but you can have an IP without DNS for a while).

  • VPS / cloud instance
  • Block storage / volumes
  • Object storage / buckets
  • Networks and firewalls

Do these in parallel with Stage 1 once you have the IP.

Stage 3: Services

The software running on the substrate. These need both identity (for SSL, mail deliverability, OAuth callbacks) and substrate (to run on).

  • Web servers
  • Databases
  • Mail servers
  • Reverse proxies
  • Authentication providers

Do these only after Stages 1 and 2 are in place. Trying to set up a service without DNS means you'll have to reconfigure it later when you wire up DNS, and most of the time you'll forget some setting.

Stage 4: Integrations

External systems that talk to your services or vice versa. They need the services to exist and be reachable.

  • Payment processors (Stripe, PayPal)
  • Email senders (Postmark, Resend, SES)
  • Analytics
  • Monitoring and alerting
  • CI/CD pipelines
  • OAuth provider apps

Do these last. Most provide a setup wizard that wants to verify your callback URL or email-from domain — both of which are Stage 3 outputs.

Common order mistakes

Setting up the mail server before DNS. You can't get good deliverability without SPF, DKIM, DMARC, and PTR. Doing it backwards burns IP reputation that takes weeks to recover.

Worksheet contrasting a wrong vs right setup order, with strikethroughs and ticks

A wrong order blocks on itself, forces redos, or fails silently. A right order falls out of the dependency model.

Configuring CI/CD before secrets management. You write the deploy job, then realise you need a secret store. Now you have to refactor every job.

Pointing DNS at production before the service is hardened. External scanners will find your service within hours. Set up the firewall first, even if it means using a temporary subdomain that's not announced.

Buying SSL certificates before deciding the domain structure. You'll pay for certs you don't need or you'll need certs you didn't buy. With Let's Encrypt this is free and reversible, but with paid CAs it's annoying.

Configuring OAuth callback URLs to "localhost" because you haven't deployed yet. You'll never remember to update them. Deploy a stub first, get a real URL, configure OAuth against the real URL.

A worked example: standing up a small SaaS

You're launching myproduct.com. Here's the order:

Stage 1 (identity)

  1. Buy myproduct.com
  2. Set DNS provider (Cloudflare, Route 53, etc.)
  3. Add DNS records: A for root + CNAME www → root, MX for mail., TXT for SPF
  4. Decide email subdomain (mail.myproduct.com)

Stage 2 (substrate)

  1. Provision VPS / VM
  2. Set PTR on the VPS IP to mail.myproduct.com
  3. Configure firewall (allow 80, 443, 22; block everything else by default)

Stage 3 (services)

  1. Install reverse proxy (Caddy, Traefik, nginx)
  2. Get TLS cert for myproduct.com and *.myproduct.com
  3. Deploy app behind reverse proxy
  4. Set up database with off-host backups
  5. Install mail server (or skip — see Stage 4)

Stage 4 (integrations)

  1. Configure transactional email provider (Postmark/Resend) — verify myproduct.com domain via DKIM record (added to Stage 1 DNS)
  2. Configure Stripe — webhook URL points at https://myproduct.com/api/webhooks/stripe
  3. Connect monitoring (UptimeRobot, BetterStack) — checks https://myproduct.com/health
  4. Set up CI/CD secrets and deploy job

Skip a step in stages 1–3 and you'll discover it in stage 4 when something refuses to verify your domain or callback.

When the model breaks down

The four-stage model works for ~90% of setups. It breaks for a few legitimate cases:

  • Cloud-managed services that bundle everything. AWS Amplify, Vercel, Cloudflare Pages — these compress the four stages into a single guided flow and you don't really get a choice on order.
  • Existing infrastructure. When you're adding to a running system, the constraints come from the system, not the model.
  • Disaster recovery. Restoring from backup, you'll do stages out of normal order because the substrate is already there.

For a fresh setup, though, identity → substrate → services → integrations almost always works.

The asking pattern is the lesson

When you see beginners asking sequencing questions, what they're really asking is: "Which of these things depends on which?" That's the right instinct. The wrong response is to memorise the order from a tutorial. The right response is to learn the dependency model so you can reason about novel setups without a checklist.

A checklist saves you once. A model saves you every time.

onboardingchecklistsetup-orderinfradevops