Deployment, CI/CD and Monitoring

At 4+ years, interviewers stop asking "have you used Vercel?" and start asking "your deploy broke checkout for 3% of users; what do you do in the first ten minutes?" This lesson gives you the vocabulary and the answers. It does not repeat the hands-on AWS steps. For those, read DevOps, Lesson 9 (Docker), Lesson 14 (CI/CD with GitHub Actions) and Lesson 17 (Monitoring with CloudWatch). For structured logs and correlation IDs, read Backend, Lesson 5. Here we focus on what is asked in the room: the Vercel model, a tested Docker setup, pipeline design, release safety, Sentry, OpenTelemetry and SLOs.

I ran the Docker build and the sample code in this lesson myself (Node 22, Next.js 16, Docker 29). Where I describe a Vercel feature, I only state what the platform documents; numbers such as time limits change, so check your plan.

Words used in this lesson

• Deployment is one built, versioned copy of your app that is running somewhere. Every push can create a new one.
• CI (continuous integration) is a habit and a tool that builds and tests every change automatically. CD (continuous delivery or deployment) carries a tested build to an environment, sometimes with a human click, sometimes without.
• An environment is a named place the app runs, such as production, staging or preview, each with its own settings and data.
• A container image is a read-only package with your app and everything it needs to run. A container is a running copy of an image. Think of the image as a recipe card and the container as the meal.
• A rollback is going back to the previous good version. A rollout is moving traffic to a new version.
• Observability means you can understand what a running system is doing from the data it emits. The three common kinds of data are logs, metrics and traces (below).
• An SLI (service level indicator) is a number that measures user happiness, such as "the share of requests that succeed". An SLO (service level objective) is the target for it, such as "99.9% over 30 days". An error budget is the allowed failure left: 100% minus the SLO.

1. The Vercel deployment model

Vercel is a hosting platform that builds your repository on every push and serves the result from a global network. The ideas matter more than the buttons.

Because deployments are immutable, a rollback is a pointer move, not a rebuild. That is the main reason Vercel feels safe. You can also build a preview, test it, and promote exactly that build to production, so what you tested is what you ship.

Environment variables: build time or run time?

An environment variable is a named setting, such as DATABASE_URL, that lives outside your code. Three rules decide most bugs:

1. Server-only by default. A variable is only readable on the server unless its name starts with NEXT_PUBLIC_.
2. NEXT_PUBLIC_ values are inlined at build time. The build replaces process.env.NEXT_PUBLIC_X with the literal text in the browser bundle. Changing the variable later changes nothing until you build again. This also means that one Docker image built once cannot serve different public values in different environments.
3. Changes apply to new deployments. On Vercel, editing a variable does not change a deployment that already exists. You must redeploy.

Use the VERCEL_ENV system variable (production, preview or development) to branch behaviour, for example to send analytics only in production. Do not use NODE_ENV for that: Vercel builds previews with NODE_ENV=production too.

Functions, cold starts and the edge

A serverless function is code that runs only when a request arrives, on a machine you do not manage. Your Route Handlers, Server Actions and server-rendered pages become functions on Vercel.

A cold start is the extra delay when a request needs a new instance that must start up, load your code and open connections. A warm start reuses an instance that is already running. Think of a food truck: the first order of the day needs the stove lit.

What reduces cold-start pain:

• Smaller code to load. Avoid importing huge libraries on the hot path. Use dynamic import() for rare features.
• Reuse instances. Vercel's Fluid compute lets one instance handle many requests at once and stay alive between them, so cold starts happen less often.
• Put the function near the database. One request often makes several database calls. If the function runs in Frankfurt and the database is in Virginia, every call pays about 80 ms or more. Set the function region to match the database.
• Pool connections. Many instances opening many database connections can exhaust the database. Use a pooler or the database's serverless driver. In Fluid compute, Vercel's attachDatabasePool helper makes sure idle pool clients are released before an instance is suspended.

The edge means running code on servers close to the user, in many cities. The old Edge Runtime had a small API (no full Node.js) and a quick start.

ISR and caching on Vercel

ISR (Incremental Static Regeneration) serves a prebuilt page from cache, and rebuilds it in the background after a time you choose or when you ask. The full Next.js story is in Next.js, Lesson 5. The deployment questions are different:

• On Vercel, the prebuilt page and the cache live in the platform, shared by all users, and revalidateTag / revalidatePath purge them for you.
• Self-hosted, the default cache is on the local disk and in memory of each server instance. With three containers, revalidateTag on one container does not clear the other two. You need a shared cache handler (for example one backed by Redis) and tag coordination. The docs say this plainly.
• Static files with a hash in the name get Cache-Control: public, max-age=31536000, immutable. Pages that read request data get private, no-cache, no-store, so a CDN will not keep them.

Version skew

Version skew is the mismatch when a browser still runs the old JavaScript while the server has the new version. Symptoms: a missing chunk file, or "Failed to find Server Action". Vercel's Skew Protection routes a client to the deployment it started on. Self-hosted, set deploymentId in next.config and use one shared NEXT_SERVER_ACTIONS_ENCRYPTION_KEY across all instances.

2. Docker for a Next.js app (built and tested)

Docker is a tool that builds container images and runs containers. The hands-on setup on a server is in DevOps, Lesson 9. Here is what an interviewer wants to hear: why each line exists.

I used output: "standalone" in next.config.ts. Standalone output makes next build write a small folder with a server.js and only the node_modules files the app really needs. Then I built this Dockerfile:

# syntax=docker/dockerfile:1# 1) deps: only the package files, so this layer is cached until they changeFROM node:22-alpine AS depsWORKDIR /appCOPY package.json package-lock.json ./RUN --mount=type=cache,target=/root/.npm npm ci# 2) build: compile the app (standalone output)FROM node:22-alpine AS buildWORKDIR /appCOPY --from=deps /app/node_modules ./node_modulesCOPY . .ENV NEXT_TELEMETRY_DISABLED=1RUN npm run build# 3) runtime: only what is needed to run, as a non-root userFROM node:22-alpine AS runtimeWORKDIR /appENV NODE_ENV=production \    NEXT_TELEMETRY_DISABLED=1 \    PORT=3000 \    HOSTNAME=0.0.0.0RUN addgroup -S app && adduser -S app -G appCOPY --from=build --chown=app:app /app/.next/standalone ./COPY --from=build --chown=app:app /app/.next/static ./.next/staticUSER appEXPOSE 3000HEALTHCHECK --interval=10s --timeout=3s --start-period=10s --retries=3 \  CMD node -e "fetch('http://127.0.0.1:3000/api/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"CMD ["node", "server.js"]

And a .dockerignore:

node_modules.next.git.env*Dockerfilenpm-debug.log

What I observed when I ran it:

• The container reported healthy after its start period, and /api/health returned {"ok":true}.
• docker exec <id> id printed uid=100(app), so the process is not root.
• The final image was about 330 MB on disk, of which about 240 MB is the Node base image. The app added roughly 90 MB. The build stage, with the compiler and all dev dependencies, is not in the final image.
• I started the same image twice with -e APP_ENV=staging and -e APP_ENV=prod. The page showed the different value each time, because the page reads process.env at request time (it calls connection() first, so it is rendered per request). One image, many environments.
• docker stop finished in about 0.2 seconds. node server.js is the main process, receives SIGTERM and exits. If you start the app through a shell script or npm start, the signal may never reach Node, and Docker waits 10 seconds and then kills it.

3. CI/CD with GitHub Actions

GitHub Actions is GitHub's built-in automation. A workflow is a YAML file in .github/workflows/. It has jobs, and each job has steps that run on a runner (a fresh virtual machine). The AWS version of this pipeline is in DevOps, Lesson 14. This is the shape I would draw on a whiteboard (I parsed it to check it is valid YAML):

name: cion:  pull_request:  push:    branches: [main]concurrency:  group: ci-${{ github.ref }}  cancel-in-progress: truepermissions:  contents: readjobs:  test:    runs-on: ubuntu-latest    strategy:      fail-fast: false      matrix:        node: [22, 24]    steps:      - uses: actions/checkout@v6      - uses: actions/setup-node@v7        with:          node-version: ${{ matrix.node }}          cache: npm      - run: npm ci      - run: npm run lint      - run: npm test      - uses: actions/cache@v6        with:          path: .next/cache          key: next-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-${{ hashFiles('src/**') }}          restore-keys: |            next-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-      - run: npm run build  deploy:    needs: test    if: github.ref == 'refs/heads/main'    runs-on: ubuntu-latest    environment: production    permissions:      id-token: write      contents: read    steps:      - uses: aws-actions/configure-aws-credentials@v6        with:          role-to-assume: ${{ vars.DEPLOY_ROLE_ARN }}          aws-region: eu-west-1      - run: aws sts get-caller-identity

What each part buys you:

• concurrency with cancel-in-progress cancels the old run when you push again to the same branch. It saves minutes. Do not cancel a deploy job halfway; give deploys their own group without cancel.
• permissions sets what the automatic GITHUB_TOKEN can do. Start with read-only and add only what a job needs. This limits the damage if a step is compromised.
• A matrix runs the same job for many values (here, two Node versions) in parallel. fail-fast: false lets the others finish, so you see every failure, not only the first.
• Caching. setup-node with cache: npm caches the npm download folder, keyed by the lockfile. The extra .next/cache cache is what Next.js documents for faster builds. The key uses the lockfile hash and the source hash; the restore-keys line falls back to the nearest older cache.
• needs and if order the jobs and make deploy run only for main.
• environment: production attaches the job to a GitHub Environment. You can require a reviewer to approve, and the environment holds its own secrets and variables.

Secrets and OIDC

A secret is a stored value, such as an API token, that GitHub hides in logs. Long-lived keys in secrets are a risk: if they leak, they work until someone notices.

OIDC (OpenID Connect) lets the workflow prove who it is without a stored key. GitHub issues a short-lived signed token for each run. The cloud (AWS, Google Cloud, Azure) checks that token against a trust rule such as "only repository acme/shop, environment production" and hands back temporary credentials. That is why the deploy job needs permissions: id-token: write. You store only a role name, which is not secret. A leaked role name is useless without a matching run.

Third-party actions run with your token. Pin important ones to a full commit SHA, not only to a moving tag such as v6, and let a bot (Dependabot) propose updates.

Build once, promote the same artifact

Do not rebuild for each environment. Build one artifact (a Docker image tagged with the commit SHA, or a Vercel deployment), then promote that same artifact from staging to production. If you rebuild, the production build can differ from the one you tested (a new transitive dependency, a different NEXT_PUBLIC_ value). The one exception, as seen above, is NEXT_PUBLIC_* values; this is why teams read public settings from a small /config endpoint at runtime if they need one image everywhere.

4. Environments and feature flags

A common setup is development (your laptop), preview (one per pull request), staging (a copy of production, shared) and production. The rules I follow:

• Each environment gets its own database and its own secrets. A preview deployment that points at the production database is an incident waiting to happen.
• Staging is only useful if it is similar to production: same Node version, same build, similar data shape. Not the same data. Never copy real personal data into lower environments without masking it.
• Keep config in environment variables, not in if (env === "staging") branches all over the code.

A feature flag is a switch in config that turns a feature on or off without a new deploy. It separates deploy (code is on the servers) from release (users can see it). That is how you merge unfinished work daily and still ship safely.

A percentage rollout needs a stable bucket for each user: the same user must get the same answer every time. I ran this:

import { createHash } from "node:crypto";export function bucket(flag, userId) {  const h = createHash("sha256").update(`${flag}:${userId}`).digest();  return h.readUInt32BE(0) % 100;          // 0..99}export const isOn = (flag, userId, percent) => bucket(flag, userId) < percent;

For 10,000 users, 10% turned on 1,020 users and 50% turned on 4,933. Everyone who was on at 10% was still on at 50%, and the same user got the same answer on repeat calls. Hashing the flag name together with the user ID means different flags pick different 10% groups, so the same unlucky users are not always the guinea pigs.

5. Zero-downtime deploys, rollbacks and database migrations

Zero-downtime deployment means users do not see errors while a new version replaces the old one. Four common strategies:

Vercel's immutable deployments behave like blue-green: the old deployment still exists after the switch, so rollback is quick. Vercel also has rolling releases for production, which move traffic in stages (such as 10%, 50%, then 100%) with approval steps.

For your own servers or containers, three things make a rolling update safe:

1. A readiness check. The load balancer sends traffic only to instances that say they are ready.
2. Graceful shutdown. On SIGTERM, the instance stops accepting work, finishes requests in flight, then exits. The step-by-step code is in Node.js and Express, Lesson 6. Next.js also finishes in-flight requests and pending after() callbacks when it gets SIGTERM or SIGINT, so give the platform a drain period (the Next.js docs suggest 10 to 30 seconds).
3. Backward-compatible clients and servers, because for a short time the browser and server versions differ (version skew, above).

Rollback: what you can and cannot undo

Rolling back code is easy. Rolling back data is not. If the new version wrote rows in a new shape, going back to old code may break. So the rule is: make every change safe to roll back, or make it small enough to roll forward fast.

Database migrations in deploys

A migration is a versioned script that changes the database structure. With Prisma, the production command is prisma migrate deploy. It applies pending migration files, does not use a shadow database, does not check for drift, and does not reset anything. The Prisma docs say to run it from an automated pipeline, not from a laptop. It takes an advisory lock with a 10 second timeout, so two deploys do not migrate at the same time; if it times out, you run it again. It is not supported on MongoDB, where Prisma uses db push and there is no migration history, so schema changes there need your own care.

Where do you run it? Not in the container's start command. If five instances start together, they all try to migrate. Run it once, as its own pipeline step or a one-off job, before the new code goes live. That means the database must work with both the old and the new code. This is the expand and contract pattern:

1. Expand: add the new column as nullable (or add a new table). Old code ignores it. Deploy the migration.
2. Deploy new code that writes both old and new fields and reads the new one.
3. Backfill old rows in small batches.
4. Contract: after the old code is gone for good, make the column required and drop the old one, in a later deploy.

To rename a column safely, never run a plain rename in one step. That breaks the old code the moment it runs. Add the new column, copy, switch, and remove the old one later.

6. Error tracking with Sentry

Sentry is a service that collects errors from your app and groups them into issues, with the stack trace, the browser, the user (if you set one), the release and the steps before the error (breadcrumbs). It also records performance traces. Compare with logs: a log is a line you wrote; Sentry is the safety net for what you did not expect.

Core terms:

• A DSN is the URL that tells the SDK where to send events. It is not a secret (it ships to the browser), but you should still limit what it can do through project settings.
• A release is a version label, usually the git commit SHA. Sentry uses it to say "this error started in release a1b2c3" and to show regressions.
• An environment is a tag such as production or preview, so preview noise does not hide real problems. The default is production, so set it explicitly.
• A source map is a file that maps the minified, bundled code in production back to your original files and line numbers. Without it, a stack trace says a.js:1:48210.

For Next.js, the @sentry/nextjs package wraps your config. Source maps are uploaded at build time using an auth token that lives in CI only. I checked these option names in the package's type definitions:

// next.config.tsimport { withSentryConfig } from "@sentry/nextjs";export default withSentryConfig(nextConfig, {  org: "acme",  project: "shop",  authToken: process.env.SENTRY_AUTH_TOKEN, // CI only, never NEXT_PUBLIC  widenClientFileUpload: true,              // also upload maps for dependencies (slower build)  tunnelRoute: "/monitoring",               // send events through your server to dodge ad blockers  sourcemaps: { deleteSourcemapsAfterUpload: true }, // default true: maps are not served to users});

// instrumentation-client.ts (browser)import * as Sentry from "@sentry/nextjs";Sentry.init({  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,  environment: process.env.NEXT_PUBLIC_VERCEL_ENV ?? "development",  tracesSampleRate: 0.1,   // keep 10% of traces  sampleRate: 1.0,         // keep all errors (the default)});

// instrumentation.ts (server)import * as Sentry from "@sentry/nextjs";export const onRequestError = Sentry.captureRequestError;

onRequestError is the Next.js hook that gets server errors from Server Components, Route Handlers and Server Actions; Sentry provides a ready function for it.

Sampling means keeping only a share of events to control cost and noise. Two knobs matter:

• sampleRate applies to error events. Default is 1.0 (keep all). You rarely lower it.
• tracesSampleRate applies to performance traces. Set it low on busy sites. If you also set tracesSampler (a function), the function wins and tracesSampleRate is ignored. Use the function to keep all checkout traces and drop health-check traces.

Good Sentry hygiene: tag releases with the commit SHA, set the user ID (not email) with Sentry.setUser, scrub personal data in beforeSend, ignore known noise (browser extension errors, cancelled requests), and route alerts by ownership, not to everyone.

7. Logs, metrics, traces and OpenTelemetry

Three kinds of data answer three questions:

Detailed log design is in Backend, Lesson 5. The CloudWatch version of metrics and alarms is in DevOps, Lesson 17.

Percentiles matter more than averages. p95 means 95% of requests were faster than this number. An average of 200 ms can hide a p99 of 6 seconds that hurts your best customers.

OpenTelemetry (OTel) is a vendor-neutral standard, with libraries, for producing traces, metrics and logs. You instrument once, then choose where to send the data (Sentry, Grafana, Datadog, Honeycomb) by changing an exporter. Terms:

• A span is one timed step (for example "db.insert order") with attributes (key and value pairs).
• A trace is all the spans for one request, joined by a trace ID.
• Context propagation means passing the trace ID from service to service in an HTTP header (the standard header is traceparent), so spans from different services join into one trace.
• An exporter sends data out. A collector is an optional separate process that receives, filters and forwards telemetry.

I ran this with @opentelemetry/sdk-node and printed the spans to the console:

const tracer = trace.getTracer("orders");await tracer.startActiveSpan("POST /orders", async (parent) => {  await tracer.startActiveSpan("db.insert order", async (child) => {    await db.insert(order);    child.end();  });  try { await charge(card); }  catch (e) {    parent.recordException(e);    parent.setStatus({ code: SpanStatusCode.ERROR });  }  parent.end();});

The output showed both spans with the same traceId, the child pointing at the parent through parentSpanContext, the service name orders-api on the resource, and the failed parent carrying an exception event with the message and stack and status: { code: 2 } (error).

In Next.js you create an instrumentation.ts file with a register() function. It runs once when a server instance starts. The simplest setup is registerOTel('next-app') from @vercel/otel, which also works in the edge runtime. For full control you configure NodeSDK yourself, and you must import it only when process.env.NEXT_RUNTIME === 'nodejs', because it does not run on the edge. Next.js already creates spans for requests, rendering and fetch calls; set NEXT_OTEL_VERBOSE=1 to see more.

8. Alerting and SLOs

A bad alert system has two failures: nobody is told about a real outage, or everyone is told about everything and learns to ignore it. Alert fatigue is when so many alerts fire that people stop reacting.

Rules that work:

• Alert on symptoms users feel (error rate, slow checkout), not on causes (CPU at 80%). CPU at 80% may be perfectly healthy.
• Every page must be actionable and urgent. If it can wait until morning, send a ticket instead of a page.
• Link each alert to a runbook: a short document with what it means, how to check, and how to fix.
• Use the four golden signals as a starting set: latency, traffic, errors and saturation (how full the system is).

The SLO gives you a calm way to decide how much failure is acceptable. I computed the error budget for a 30-day month:

Each extra "9" costs far more than the one before. Most product teams do not need 99.99%, and a third-party service you depend on may not offer it anyway.

Burn rate is how fast you spend the error budget compared with an even spend. A burn rate of 1 uses the whole budget in exactly the full window. A burn rate of 14.4 for one hour uses 2% of a 30-day budget; 6 for six hours uses 5%; 1 for three days uses 10%. A well-known pattern pages on a fast burn (such as 14.4 over 1 hour) and opens a ticket on a slow burn. This catches a sudden outage in minutes but ignores a one-minute blip.

If the budget is nearly gone, the team slows feature releases and spends time on reliability. If plenty is left, ship faster. That turns "reliability versus speed" from an argument into a number.

Common mistakes

• Rebuilding per environment, so production runs something nobody tested.
• Running prisma migrate deploy in every container's start command.
• A dropped or renamed column in the same deploy as the code that stops using it.
• NEXT_PUBLIC_ on a secret, or editing a variable and expecting the live site to change without a redeploy.
• Running the container as root, copying .env into the image, or using latest as the only tag. Tag images with the commit SHA.
• Uploading source maps from your laptop, or serving them publicly.
• Alerting on CPU instead of user pain; no runbook; one shared channel nobody reads.
• Treating a health endpoint as "returns 200 always". A health check that never checks anything cannot warn you.

Interview questions

Key takeaways

• A deployment is immutable. Rollback is moving a pointer or a flag, not rebuilding. Build once and promote the same artifact.
• NEXT_PUBLIC_* is baked in at build. Secrets stay server-side. Variable changes need a redeploy.
• Run data-heavy code near the data. The edge is for light, data-free work, and the Edge Runtime option is deprecated in current Next.js.
• A good Dockerfile is multi-stage, uses the lockfile, copies the least it can, runs as a non-root user, starts node directly, and has a real health check. A .dockerignore is part of it.
• In CI: cache, parallelize, cancel old runs, give each job least-privilege permissions, and use OIDC instead of stored cloud keys with a narrow trust rule.
• Migrations run once, before the new code, as expand then contract. Never drop or rename in the same release.
• Feature flags separate deploy from release. Use stable hashing for percentages, keep a kill switch and delete old flags.
• Sentry shows the error, the release and who is hit. Upload source maps in CI and do not serve them. tracesSampler overrides tracesSampleRate.
• Logs tell the story, metrics tell you something is wrong, traces tell you where. OpenTelemetry keeps you free of one vendor.
• Alert on user pain, not on causes. SLOs and burn rates turn "is this bad enough?" into a number.

What's next

To build the same pipeline on real servers, follow the DevOps series, starting with Docker, CI/CD and Monitoring. For log design, revisit Backend, Lesson 5. Then practise answering Q20 out loud, with a timer, using one of your own past incidents.