Guided Course · Phases 32–35

Docker, CI/CD, Vercel & Production Delivery

Package, verify, release, deploy, observe, and roll back TaskFlow as a production system.

Track project: Release TaskFlow. Finish the lessons, then close the transcript and build the project using evidence instead of copy-paste. Open project →
01

Docker Mental Model

Here’s the simple reason this matters: An image is an immutable filesystem/runtime template; a container is a running isolated process created from that image. Containers still use ordinary processes, files, ports, and networks. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1892 words
02

First Dockerfile

Here’s the simple reason this matters: This lesson is about First Dockerfile. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the simple image can run the app but deliberately leaves optimization/security improvements for later lessons. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1938 words
03

Build Context and .dockerignore

Here’s the simple reason this matters: This lesson is about Build Context and .dockerignore. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that unneeded local artifacts and secrets are excluded from the build context before Docker sends files to the builder. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 2027 words
04

Layers and Cache

Here’s the simple reason this matters: This lesson is about Layers and Cache. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that dependency installation can stay cached when application source changes but dependency manifests do not. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1961 words
05

Multi-Stage Build

Here’s the simple reason this matters: This lesson is about Multi-Stage Build. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that build tools remain in the build stage while the runtime stage receives only artifacts needed to start the API. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1980 words
06

Non-Root Runtime

Here’s the simple reason this matters: This lesson is about Non-Root Runtime. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the application process no longer runs as root inside the container. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1905 words
07

Runtime Environment Variables

Here’s the simple reason this matters: This lesson is about Runtime Environment Variables. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that secrets/config are supplied when the container starts rather than baked into the image layer history. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1973 words
08

Health Checks

Here’s the simple reason this matters: This lesson is about Health Checks. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the runtime can report whether the application process is responding, though platform readiness may need a dependency-aware endpoint too. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1962 words
09

Docker Compose

Here’s the simple reason this matters: This lesson is about Docker Compose. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that compose describes a repeatable local multi-container application topology. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1886 words
10

Container Networking

Here’s the simple reason this matters: Inside a container, `localhost` means that container itself. Containers on the same Compose network reach each other by service name. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1842 words
11

API + PostgreSQL Compose Lab

Here’s the simple reason this matters: This lesson is about API + PostgreSQL Compose Lab. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the local stack starts, the host can reach the published API port, logs are inspectable, and PostgreSQL is reachable inside the Compose network. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 2073 words
12

GitHub Actions Triggers

Here’s the simple reason this matters: This lesson is about GitHub Actions Triggers. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that pull requests run verification before merge and pushes to main can drive post-merge/release automation. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1967 words
13

Jobs and Runners

Here’s the simple reason this matters: A GitHub Actions job is a set of steps scheduled on a runner. The runner is the machine that actually checks out code and executes those commands. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1897 words
14

Deterministic pnpm Install

Here’s the simple reason this matters: This lesson is about Deterministic pnpm Install. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that cI uses the declared package-manager version and refuses to silently rewrite an outdated lockfile. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1966 words
15

Lint, Typecheck, Test, Build

Here’s the simple reason this matters: This lesson is about Lint, Typecheck, Test, Build. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that separate quality-gate steps make the failing category obvious in CI logs. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1982 words
16

Workflow Permissions

Here’s the simple reason this matters: Workflow permissions define what the GitHub token used by a job is allowed to do. Start read-only and grant only the capabilities a job needs. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1847 words
17

CI Secrets

Here’s the simple reason this matters: This lesson is about CI Secrets. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that secrets enter only trusted jobs and are not committed, printed, or passed to untrusted execution contexts. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1943 words
18

Artifacts

Here’s the simple reason this matters: This lesson is about Artifacts. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that a job can preserve generated reports or build output for later inspection/jobs without committing them to Git. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1911 words
19

Concurrency

Here’s the simple reason this matters: CI concurrency controls overlapping workflow runs. It is especially useful for canceling obsolete preview/deploy runs when a newer commit supersedes them. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1787 words
20

Branch Protection

Here’s the simple reason this matters: This lesson is about Branch Protection. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that repository policy prevents unverified code from bypassing the quality gate. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1898 words
21

Release Workflow

Here’s the simple reason this matters: This lesson is about Release Workflow. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that release is a repeatable pipeline with a known artifact and explicit verification, not a sequence of manual guesses. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1956 words
22

Production Migration Step

Here’s the simple reason this matters: This lesson is about Production Migration Step. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that production applies already-reviewed migrations and verifies migration state instead of creating new migrations during deploy. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1966 words
23

Deploy NestJS API

Here’s the simple reason this matters: This lesson is about Deploy NestJS API. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the API deployment is successful only after the runtime is healthy and ready for traffic. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1972 words
24

Deploy Next.js to Vercel

Here’s the simple reason this matters: This lesson is about Deploy Next.js to Vercel. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that vercel builds the documentation/web app from Git and production configuration is kept outside source code. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 2055 words
25

Production CORS

Here’s the simple reason this matters: CORS is a browser-enforced policy controlling whether frontend JavaScript from one origin may read responses from another origin. It is not authentication. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1824 words
26

DNS and TLS

Here’s the simple reason this matters: This lesson is about DNS and TLS. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that users reach stable hostnames over valid TLS before application-layer authentication even begins. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1955 words
27

Smoke Tests

Here’s the simple reason this matters: Smoke tests are a small set of high-value checks run after deployment to prove the released system is alive and its critical path works. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1843 words
28

Post-Deploy Observation

Here’s the simple reason this matters: This lesson is about Post-Deploy Observation. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that a release remains under observation long enough to catch runtime regressions that build-time checks cannot reveal. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1941 words
29

Rollback Runbook

Here’s the simple reason this matters: Rollback restores a known previous client state after an optimistic mutation fails. It works only if the prior state was captured before the optimistic write. In this course, we connect it directly to containers, CI/CD, Vercel, production release, smoke testing, and rollback, so you can see where the idea lives in a real project instead of memorizing a definition.

≈ 1854 words
30

Post-Release Architecture Review

Here’s the simple reason this matters: This lesson is about Post-Release Architecture Review. Keep the idea practical: in containers, CI/CD, Vercel, and production delivery, the worked example should show that the team turns release evidence into concrete architectural/process improvements instead of adding tools by fashion. Once you can explain why that happens, the name is much easier to remember. We connect it to the course project so you can see the idea working instead of memorizing a definition.

≈ 1985 words
Track knowledge check

Check the mental models before the project

Answer from memory. If two options sound similar, explain the boundary difference before choosing.

0/0 correct · 0/10 answered
01Which statement best explains “Docker Mental Model” in this track?
02Which statement best explains “First Dockerfile” in this track?
03Which statement best explains “Build Context and .dockerignore” in this track?
04Which statement best explains “Layers and Cache” in this track?
05Which statement best explains “Multi-Stage Build” in this track?
06Which statement best explains “Non-Root Runtime” in this track?
07Which statement best explains “Runtime Environment Variables” in this track?
08Which statement best explains “Health Checks” in this track?
09Which statement best explains “Docker Compose” in this track?
10Which statement best explains “Container Networking” in this track?
Ready to transfer the skill?

Release TaskFlow

Package the API, verify it in CI, deploy API + web, and prove the production release with smoke tests and rollback notes.

Start track project →