🚀 Weekend Project: Deploy & Monitor a Full-Stack App

The Goal

Take the containerized app from Week 11 and make it real. Right now it runs on your laptop with one docker compose up. This weekend it gets an address the world can type into a browser, a lock icon next to that address, a database that a cloud provider keeps alive and backed up for you, a robot that redeploys it every time you push, and a pair of eyes — a dashboard and an alert — that never blink. The finish line is a URL you can text to a friend and a pipeline that turns git push into a live release with no manual steps.

The through-line of the whole week has been one idea: the path from repo to production should be automated, observable, and reversible. Automated so humans don't hand-copy files to servers at midnight. Observable so you learn about failures from a graph, not from an angry user. Reversible so a bad release is a thirty-second rollback, not an outage. Every stage below serves one of those three words.

Prerequisites

This is the Week 13 capstone. It assumes the cloud and DevOps ideas you built up all week, plus the container work from Week 11 and the CI groundwork from Week 12. Before you start, be comfortable with:

You'll also need a few accounts, all with free tiers big enough for this project: a cloud PaaS account, a domain name you control (a cheap .dev or .app is perfect and forces HTTPS), and your existing GitHub repo. Confirm your local toolbelt first:

# Git and the GitHub CLI (handy for setting repo secrets from the terminal)
git --version
gh --version

# Docker, to build and sanity-check the production image locally before shipping
docker --version

Required Features Checklist

These are the non-negotiables. Each maps to a stage below. Tick them off as you go — the rubric at the end grades against this same list.

The Deployed Architecture

Here is the shape of what you're building. A user's browser hits your domain; DNS points it at the platform's edge, which terminates TLS and routes to your running container; the app talks to a managed Postgres over a private network; and a monitoring layer watches every piece, escalating to an alert when a threshold trips. The GitHub repo feeds the whole thing through CI/CD.

Two properties make this a production topology rather than a demo. First, the database is managed and private: the provider handles backups, patching, and failover, and the connection string is only reachable from inside the platform's network — never exposed to the open internet. Second, deployment is one-directional and automated: code flows from the repo through CI/CD into the running app, and the running app never becomes the source of truth. If the server disappears, you rebuild it from the repo, not from a snapshot of a hand-edited box.

The monitoring layer is not an afterthought bolted on at the end — it's a first-class edge in this diagram. Every request the app serves emits a structured log line and contributes to a metric, and those feed a dashboard and, above a threshold, an alert. You're building the nervous system alongside the muscles.

Project & Infra Structure

You already have the app. This weekend you add a thin layer of infrastructure and pipeline config beside it — a platform manifest, a deploy workflow, and a little logging and health-check code. Everything is committed to Git, because the setup instructions are the code now.

fullstack-app/
├── compose.yaml                <-- from Week 11, still used for local dev
├── render.yaml                 <-- platform manifest: services, DB, health path, env
├── client/                     <-- React (Vite) SPA + its Dockerfile
├── server/                     <-- Express API + its Dockerfile
│   └── src/
│       ├── server.js           <-- app entry
│       ├── logger.js           <-- structured JSON logging (pino)
│       └── routes/
│           └── health.js       <-- /healthz (liveness) + /readyz (readiness)
├── .github/
│   └── workflows/
│       └── deploy.yml          <-- CI/CD: build + test + deploy on push to main
├── monitoring/
│   └── alerts.md               <-- what each alert means + how to respond (runbook)
├── docs/
│   └── ROLLBACK.md             <-- the rollback plan you will rehearse
├── .env.example                <-- template of required env vars (committed)
└── README.md                   <-- how to deploy, links to the live URL + dashboard

Stage 1 — Provision the Infrastructure

Before code can go live, the place it lives has to exist. In PaaS terms, "provisioning" means declaring your services and their managed database in the platform manifest, then letting the platform create them. Here's a Render-style render.yaml that declares a web service built from your Dockerfile and a managed Postgres beside it.

# render.yaml — declarative infrastructure for the whole app.
services:
  - type: web
    name: fullstack-app
    runtime: docker
    dockerfilePath: ./server/Dockerfile
    dockerContext: ./server
    plan: free
    # The platform hits this path to decide if the container is healthy.
    healthCheckPath: /healthz
    autoDeploy: false            # CI drives deploys, not the platform's git hook
    envVars:
      - key: NODE_ENV
        value: production
      - key: PORT
        value: "3000"
      # Pull the DB connection string straight from the managed database below.
      - key: DATABASE_URL
        fromDatabase:
          name: fullstack-db
          property: connectionString
      - key: LOG_LEVEL
        value: info

databases:
  - name: fullstack-db
    plan: free
    databaseName: appdb
    user: appuser

Read that top to bottom and it's a full environment: one web service built from a Dockerfile, wired to a managed Postgres whose connection string is injected as DATABASE_URL. No password is written in the file — the platform generates the database credentials and hands them to the service through fromDatabase, so secrets never touch Git.

Commit the manifest, connect the repo to the platform once through its dashboard, and it reads render.yaml to create the service and database. On other platforms the file differs but the move is identical — declare, commit, let the platform build:

# Fly.io equivalent: a guided init writes fly.toml, then attach a managed Postgres
fly launch --no-deploy          # generates fly.toml from your Dockerfile
fly postgres create             # provision a managed Postgres cluster
fly postgres attach fullstack-db  # injects DATABASE_URL into the app's secrets

Stage 2 — Deploy the App + Managed DB

Infrastructure exists; now put the app on it and make sure it can talk to the database. Two things have to be true before you call this stage done: the container starts and answers a health check, and it connects to the managed Postgres and runs its migrations.

A real health check the platform can trust

The platform decides whether to route traffic to your container — and whether to restart it — by polling a health-check URL. A good app exposes two probes. Liveness (/healthz) answers "is the process alive?" and must never touch the database, or a slow query could get a healthy app killed. Readiness (/readyz) answers "can I actually serve requests right now?" and does check dependencies like the DB, so traffic is held back until they're reachable.

// server/src/routes/health.js
import { Router } from 'express';
import { pool } from '../db.js';   // your pg connection pool

const router = Router();

// Liveness: cheap, dependency-free. If this fails, restart the container.
router.get('/healthz', (req, res) => {
  res.status(200).json({ status: 'ok', uptime: process.uptime() });
});

// Readiness: verify the app can reach its dependencies before taking traffic.
router.get('/readyz', async (req, res) => {
  try {
    await pool.query('SELECT 1');            // can we reach Postgres?
    res.status(200).json({ status: 'ready' });
  } catch (err) {
    // 503 tells the load balancer to stop sending traffic until we recover.
    res.status(503).json({ status: 'not-ready', reason: 'database unreachable' });
  }
});

export default router;

Run migrations as part of the release, not by hand

A fresh managed database is empty. Your schema has to be applied before the app can serve real data — and it must happen automatically on every deploy so the database and the code never drift apart. Run migrations in a release step (your CI does this in Stage 4) or as the container's pre-start command:

# Apply pending migrations against the managed DB, then start the server.
# DATABASE_URL is injected by the platform from the managed database.
npm run migrate:deploy && node src/server.js

Deploy, then confirm the app is up and connected:

# Once deployed, both probes should answer over the platform URL:
curl https://fullstack-app.onrender.com/healthz
# => {"status":"ok","uptime":8.4}

curl https://fullstack-app.onrender.com/readyz
# => {"status":"ready"}   ← proves the app reached managed Postgres

Stage 3 — Custom Domain + HTTPS

The app answers at an ugly platform subdomain. Time to give it your own name and a padlock. This is where the DNS knowledge from the previous lesson pays off. The move has two halves: tell the platform that you own the domain, and tell DNS to send that domain to the platform.

Add the domain on the platform, then point DNS at it

In the platform's dashboard, add yourdomain.com (and usually www.yourdomain.com) as a custom domain. The platform gives you a target to point at. At your DNS provider, create the matching records:

DNS changes are not instant — they propagate as caches expire. Watch the record resolve from your machine while you wait:

# Follow the domain until it resolves to the platform's edge.
dig +short yourdomain.com
dig +short www.yourdomain.com CNAME

# Confirm HTTPS once the certificate is issued (should be a clean 200, not a cert error):
curl -I https://yourdomain.com

TLS that renews itself

Once DNS points at the platform and it verifies you control the domain, the platform automatically requests a certificate from Let's Encrypt and installs it — usually within a minute or two. Crucially, it also renews that certificate on its own before it expires (Let's Encrypt certs last 90 days), so you never wake up to an expired-certificate outage. It also sets up the HTTP → HTTPS redirect for you, so a visitor typing http:// lands safely on https://.

# Inspect the live certificate's validity dates.
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates
# issuer=... Let's Encrypt ...   notAfter=... about 90 days out, auto-renewed

Stage 4 — CI/CD That Ships on Push

So far you've deployed by clicking. That doesn't scale and it isn't repeatable. The heart of this project is a pipeline: push to main, and a robot builds the image, runs the tests, and — only if the tests pass — deploys. A red test suite must block the release. That single guarantee is what lets a team ship many times a day without fear.

Here is the shape of the pipeline before the code — worth internalizing, because every CI/CD system is a variation on it:

Notice the gate in the middle: tests run before the build, and a failure halts the whole run. Now the workflow. Create .github/workflows/deploy.yml:

name: Build, Test & Deploy

on:
  push:
    branches: [ main ]

# Cancel an in-flight run if a newer commit lands, so only the latest ships.
concurrency:
  group: deploy-main
  cancel-in-progress: true

jobs:
  test:
    name: Install and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
          cache-dependency-path: server/package-lock.json

      - name: Install dependencies
        working-directory: server
        run: npm ci

      - name: Run the test suite
        working-directory: server
        run: npm test        # a red suite fails the job and blocks deploy

  deploy:
    name: Build image and deploy
    needs: test              # only runs if the test job passed
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build the production image
        run: docker build -t fullstack-app:${{ github.sha }} ./server

      # Trigger the platform's deploy. The deploy hook URL is stored as a
      # repository secret, never committed to the workflow file.
      - name: Deploy to the cloud platform
        run: curl -fsSL -X POST "${{ secrets.RENDER_DEPLOY_HOOK_URL }}"

      - name: Report the deployed version
        run: echo "Deployed commit ${{ github.sha }} to production"

The needs: test line is the whole point: the deploy job refuses to run unless test succeeded. The concurrency block prevents two deploys from racing when you push twice quickly. And the deploy hook lives in repository secrets, not in the file — set it once from the terminal:

# Store the platform's deploy hook URL as an encrypted repo secret.
gh secret set RENDER_DEPLOY_HOOK_URL --body "https://api.render.com/deploy/srv-xxxx?key=yyyy"

Stage 5 — Monitoring, Logging & an Alert

An app you can't see inside of is an app you're flying blind. This stage gives you three senses: logs (what happened, in detail), metrics (how much and how fast, over time), and alerts (a tap on the shoulder when something's wrong). You want all three before you have real users, not after your first outage.

Structured logging you can actually search

Plain console.log("user logged in") is invisible at scale — you can't filter or aggregate free-form text. Structured logging emits each event as JSON with a level, a timestamp, and named fields, so a log platform can search "show me every error for user 42 in the last hour." Use pino, the fast standard for Node:

// server/src/logger.js
import pino from 'pino';

export const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  // Redact anything sensitive so tokens never land in your logs.
  redact: ['req.headers.authorization', 'req.headers.cookie'],
  formatters: {
    level: (label) => ({ level: label }),   // human-readable level names
  },
});

// server/src/server.js — attach a request logger with a correlation id.
import { logger } from './logger.js';
import { randomUUID } from 'node:crypto';

app.use((req, res, next) => {
  req.id = req.headers['x-request-id'] || randomUUID();
  const child = logger.child({ reqId: req.id, method: req.method, path: req.path });
  res.on('finish', () => {
    child.info({ status: res.statusCode, ms: Date.now() - req.startTime }, 'request completed');
  });
  req.startTime = Date.now();
  req.log = child;
  next();
});

Each request now produces a searchable JSON line with a correlation id that ties every log for one request together — priceless when you're chasing a single user's failing session through thousands of events. Your platform captures stdout automatically, so these lines flow straight into its log viewer with no extra shipping code.

{"level":"info","time":1719800000000,"reqId":"a1b2-c3d4","method":"GET",
 "path":"/api/tasks","status":200,"ms":37,"msg":"request completed"}

A metrics dashboard

Metrics are numbers over time: request rate, latency percentiles, error rate, CPU, and memory. Your platform ships a built-in dashboard for CPU/memory/response-time out of the box — pin it and know what "normal" looks like. To watch application-level signals, expose a /metrics endpoint in Prometheus format and point a hosted Grafana (or the platform's own metrics) at it:

// server/src/metrics.js — expose app metrics for a dashboard to scrape.
import client from 'prom-client';

client.collectDefaultMetrics();   // process CPU, memory, event-loop lag

export const httpDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request latency in seconds',
  labelNames: ['method', 'route', 'status'],
  buckets: [0.05, 0.1, 0.3, 0.5, 1, 2, 5],
});

export function metricsHandler(req, res) {
  res.set('Content-Type', client.register.contentType);
  client.register.metrics().then((data) => res.end(data));
}

Track the four signals that catch most incidents — often called the "golden signals": latency, traffic, errors, and saturation (how full your resources are). A dashboard with those four panels tells you at a glance whether the app is healthy.

At least one alert that reaches you

A dashboard only helps when someone's looking at it. An alert watches a metric for you and notifies you the moment it crosses a line. Configure at least one — a high 5xx error rate is the highest-value first alert. In your monitoring tool (the platform's alerting, Grafana, Better Stack, and the like), the rule reads like this:

# A Prometheus-style alert rule: page us when the app starts erroring.
groups:
  - name: fullstack-app
    rules:
      - alert: HighErrorRate
        # More than 5 percent of requests are 5xx over the last five minutes.
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Error rate above 5 percent for 5 minutes"
          runbook: "See monitoring/alerts.md — check recent deploy, then roll back if needed"

Wire the alert's notification channel to somewhere you'll actually see it — email, a Slack channel, or PagerDuty. Then write down what to do when it fires, so a 2 a.m. page is a checklist, not a puzzle:

# monitoring/alerts.md — the runbook

## HighErrorRate (5xx > 5% for 5m)
1. Open the metrics dashboard — is latency also up? Is it one route or all?
2. Check the logs for the correlation ids on the failing requests.
3. Did a deploy land in the last 30 minutes? If yes, ROLL BACK first (docs/ROLLBACK.md),
   investigate second. Reverting is faster than debugging under fire.
4. If it is the database, check the managed DB's status page and connection count.

Stage 6 — Verify & Run a Rollback Drill

A deployment isn't done when it's green — it's done when you've proven the whole system, including the parts that only matter when things go wrong. Two verifications close out the weekend: an end-to-end smoke test of the live site, and a real rollback drill.

End-to-end smoke test

Walk the entire path a user takes, on the real domain:

Prove the alert fires

An untested alert is a guess. Trigger it on purpose — add a temporary route that throws, hit it a few times, and confirm the notification actually lands where you expect. Then remove the route.

# Generate a burst of 5xx responses to trip the HighErrorRate alert.
for i in $(seq 1 50); do curl -s -o /dev/null https://yourdomain.com/api/boom; done
# → within a few minutes you should receive the alert notification

The rollback drill — the most important five minutes

Every deploy carries the risk of shipping a bug. What separates a calm team from a scrambling one is a rehearsed rollback: the ability to return to the last known-good release quickly and predictably. Write it down, then actually do it once so you know the steps work before you need them under pressure.

# docs/ROLLBACK.md — the rollback plan

## When to roll back
Error rate or latency spikes right after a deploy, or /readyz starts failing.
Roll back FIRST, debug SECOND — reverting is faster than fixing live.

## Option A — platform one-click (fastest)
Open the platform dashboard → Deploys → select the previous successful
deploy → "Redeploy" / "Rollback". Traffic returns to the old image in under a minute.

## Option B — revert the commit (keeps Git as source of truth)
git revert <bad-sha>      # creates a new commit that undoes the bad one
git push origin main      # CI re-runs tests and deploys the reverted code

## After rolling back
1. Confirm /healthz, /readyz, and a real user action all pass on the live site.
2. Confirm the error-rate alert has cleared on the dashboard.
3. Open an issue with the failing commit + logs so the fix goes through CI next time.

Run Option A right now as a drill: deploy a trivial visible change (say, a heading text tweak), confirm it's live, then roll back to the previous deploy and confirm the old version returns. Time it. That number — how long it takes you to undo a release — is one of the most reassuring facts you can know about your own system.

Stretch Goals

Required build done with time to spare? Push it toward how a seasoned team runs things. None of these are needed to pass the rubric — pick whatever excites you.

IaC starter — the same infra, in Terraform

# A taste of the Terraform shape (HCL). The whole environment as code,
# reviewable in a pull request and reproducible with one command.
resource "render_web_service" "app" {
  name           = "fullstack-app"
  runtime        = "docker"
  dockerfile     = "./server/Dockerfile"
  health_check   = "/healthz"
  auto_deploy    = false
}

resource "render_postgres" "db" {
  name = "fullstack-db"
  plan = "free"
}
# terraform plan  → preview changes
# terraform apply → create/update the real infrastructure

Self-Check Rubric

Before you call this done, grade yourself. Aim to answer "yes" to everything in the required column — the stretch column is bonus. This is your capstone, so be honest: a "yes" means you verified it on the live site, not that you intended to.

Summary

This is the capstone that ties Week 13 together. You didn't learn deployment, DNS, TLS, pipelines, and monitoring as separate trivia — you connected them into one continuous, automated path from git push to a live site the world can reach and you can watch. Every technique the week introduced showed up here as a working part of a whole: the container from Week 11, the tests from Week 12, and this week's cloud, DNS, and monitoring skills, wired together so the system is automated (the pipeline ships it), observable (the dashboard and alert watch it), and reversible (the rollback undoes it). That triad is what "running software in production" actually means.

📚 Additional Resources

• GitHub — Deploying with GitHub Actions
• Let's Encrypt — How automated certificates work
• Pino — fast structured logging for Node.js
• Prometheus — Instrumentation best practices
• Google SRE Book — The four golden signals
• MDN — Transport Layer Security (TLS)

🚀 What's Next?

Your app is one deployable unit — a single service that does everything. That's exactly the right choice for now, and it will carry you a long way. But as systems and teams grow, that one unit can become a bottleneck: every change redeploys everything, and one component's load drags on the rest. Week 14 opens the door to the alternative. The next lesson, Microservices Principles, examines when and why teams split a monolith into independently deployable services — and the real costs that come with that power. You now know how to deploy and monitor one service well; next you'll learn how those same skills scale to many.