Deployment Basics

Deployment turns code into a running service. A good deployment process is repeatable, observable, and reversible. The goal is not just to ship, but to ship without guessing what is running.

Build and Release

Build once, then promote the same artifact across environments when possible. Environment variables should change between staging and production, not the compiled application code.

type AppConfig = {
  databaseUrl: string;
  sessionSecret: string;
  port: number;
};

function loadConfig(env: NodeJS.ProcessEnv): AppConfig {
  if (!env.DATABASE_URL || !env.SESSION_SECRET) {
    throw new Error("Missing required configuration");
  }

  return {
    databaseUrl: env.DATABASE_URL,
    sessionSecret: env.SESSION_SECRET,
    port: Number(env.PORT ?? 3000),
  };
}

Migrations and Health Checks

Database migrations need ordering and rollback planning. A backward-compatible deployment often uses two steps: deploy code that supports old and new schema, migrate data, then remove old paths later.

Health checks let load balancers route only to ready instances.

GET /health
200 OK

WARNING

Do not mark a service healthy before it can connect to critical dependencies such as the database, cache, or message broker.

Scaling

Horizontal scaling means running more instances of the service. Stateless servers scale more easily because any instance can handle any request.

TIP

Practice rollback before an incident. A rollback plan that only exists in someone’s memory is not a plan.

Further Learning

Search these terms to go deeper:

“blue green deployment explained” — reducing release risk
“zero downtime database migrations” — safe schema changes
“health checks readiness liveness” — deployment platform checks
“twelve factor app config” — environment-based application configuration

Deployment Basics

Deployment is the process of turning your code into a live, running service. A good deployment is repeatable (do it the same way every time), observable (you can tell if it worked), and reversible (you can undo it if something’s wrong).

Same build, different settings

Build your app once, then use the same build for staging and production — only the settings (environment variables) should differ, not the actual code:

function loadConfig(env) {
  if (!env.DATABASE_URL) throw new Error('Missing required config')
  return { databaseUrl: env.DATABASE_URL, port: Number(env.PORT ?? 3000) }
}

This way you know staging and production are running the exact same code — just pointed at different databases/settings.

Health checks: don’t send traffic to a broken instance

A health check is a simple endpoint (GET /health) that says “I’m ready.” Your hosting platform checks this before sending real users your way.

WARNING

Don’t mark your service “healthy” until it can actually reach its database and other critical dependencies. A server that responds “ok” but can’t talk to its database will just fail every real request.

Have a way back out

Before you deploy, know how you’d undo it if something breaks. A rollback plan that only exists in someone’s head isn’t really a plan.

TIP

Practice your rollback process before you need it in a real emergency.

Scaling: run more copies

Horizontal scaling means running more copies of your server to handle more traffic (instead of buying one giant machine). This works best when your server doesn’t keep important state in memory — any copy should be able to handle any request.

In one sentence

Deployment should be repeatable (same build everywhere, config via environment variables), safe (health checks before routing traffic, migrations planned), and reversible (a real rollback plan) — and scaling means running more stateless copies of your server.

Want to go deeper?

Switch to Expert mode above for blue-green deployments and zero-downtime migration strategies.