Containerize a Node.js App with Docker

Write a Dockerfile, build an image, and run a Node.js app in a container.

Introduction

30 Second Summary

You've written code that runs perfectly on your computer. Then you send it to someone else, and it breaks because they have a different version of your language or a missing library.

In this project, you will build a simple web server and package it inside a Docker container. You'll watch it serve live responses right in your browser.

What You'll Build

You'll open your browser, visit a URL, and see a live greeting served from a web server running entirely inside a Docker container on your Mac.

By the end of this project, you'll have:

A working web server you can visit at localhost:3000 that serves a JSON greeting from inside a Docker container you built from scratch.
A Dockerfile you wrote yourself that packages your app into a portable image, ready to run on any machine without installing anything extra.
An optimized build that finishes in seconds when you change your code, skipping dependency reinstalls entirely thanks to layer caching.
Secret Mission: Add a second API route and configure your container with environment variables at runtime.

Are there any prerequisites?

You'll need Docker Desktop, VS Code, and Node.js installed on your Mac. No prior Docker experience is required.

Before We Start

Before you start building, let's get clear on what you're about to create and why it matters.

Set Up Your Project

Docker packages existing code into portable containers. It does not create applications for you. Before you can containerize anything, you need a working app to put inside the container.

In this step, you'll create a simple web server using Node.js and Express. Once it runs on your Mac, you'll have something real to package with Docker in the next step.

In this step, get ready to:

Create a project folder and a package.json file.
Install Express and write a minimal web server.
Run the app locally and confirm it works before containerizing.

Create the project folder and initialize it

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal and press Enter to open it.

Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir my-docker-app
cd my-docker-app

Confirm you're inside the new folder by running:

pwd

You should see a path ending in my-docker-app.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Visual Studio Code and press Enter to open it.
In VS Code, click File in the top menu bar.
Click Open Folder.
Navigate to your Desktop, select the my-docker-app folder, and click Open.

Seeing a trust dialog?

VS Code may ask if you trust the authors of the files in this folder. Click Yes, I trust the authors to continue. This is a security feature that controls which features VS Code enables for the folder.

Your VS Code Explorer sidebar should show the empty my-docker-app folder. Now you'll add the project's configuration file.

In the VS Code Explorer sidebar on the left, click the New File icon (a page with a small plus sign).
Name the file package.json and press Enter.
Copy the following code into package.json:

{
  "name": "my-docker-app",
  "version": "1.0.0",
  "description": "A simple Express app for learning Docker",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "5.1.0"
  }
}

What does this file do?

package.json is the manifest for your Node.js project. It tells Node.js your project's name, version, and which packages it depends on.

The dependencies section lists Express at version 5.1.0. When you run npm install, Node.js reads this file and downloads Express for you.

Save package.json by pressing Cmd+S (macOS) or Ctrl+S (Windows).

Seeing a red underline in package.json?

Make sure every string is wrapped in double quotes. JSON requires double quotes, not single quotes.
Check that there are no trailing commas after the last item in any list.
help me fix a JSON syntax error in my package.json

✔️ Awesome, I've got everything!

Great. Make sure you've saved package.json before moving on.

ⓧ I'd like to double check the full code

Here's the complete package.json for comparison:

{
  "name": "my-docker-app",
  "version": "1.0.0",
  "description": "A simple Express app for learning Docker",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "5.1.0"
  }
}

Install Express and write a minimal server

Switch back to your terminal and install the project's dependencies by running:

npm install

You should see output ending with a line like "added X packages". A node_modules folder also appears in the VS Code Explorer sidebar.

Seeing an error from npm?

Make sure you saved package.json before running npm install.
Confirm you're inside the my-docker-app folder by running pwd. The path should end in my-docker-app.
help me fix npm install errors

Now you'll write the web server that Express will power.

Back in VS Code, click the New File icon in the Explorer sidebar.
Name the file server.js and press Enter.
Copy the following code into server.js:

// Import the Express framework
const express = require('express');
const app = express();
const PORT = 3000;

// Define a route that returns a JSON greeting
app.get('/', (req, res) => {
  res.json({ message: 'Hello from Docker!' });
});

// Start the server and listen for requests
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

What does this code do?

require('express') loads the Express framework, which handles incoming web requests for you.
app.get('/') defines a route. When someone visits the root URL, the server responds with a JSON object containing a greeting message.
app.listen(PORT) starts the server on port 3000 and prints a confirmation message to the terminal.

Save server.js by pressing Cmd+S (macOS) or Ctrl+S (Windows).
You should see server.js listed alongside package.json and node_modules in the Explorer sidebar.

File not appearing in the Explorer sidebar?

Check the VS Code title bar. It should say my-docker-app. If it shows a different folder, go to File > Open Folder and reselect my-docker-app from your Desktop.
my server.js file isn't showing up in VS Code

✔️ Awesome, I've got everything!

Great. Make sure you've saved server.js before moving on.

ⓧ I'd like to double check the full code

Here's the complete server.js for comparison:

const express = require('express');
const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
  res.json({ message: 'Hello from Docker!' });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Run the app locally to confirm it works

Your server is written and your dependencies are installed. Before you run it, what do you think you'll see in the terminal when you start the server?

Switch back to your terminal and start the server by running:

node server.js

You should see Server running on port 3000 printed in the terminal. The server is now listening for requests, and your terminal is occupied by the running process.

Open your browser and visit http://localhost:3000.

You should see {"message":"Hello from Docker!"} displayed in the browser. Your Express server is running locally and responding to requests.

Not seeing the JSON response?

Check your terminal. If you see an error like "Cannot find module 'express'", you may not have run npm install successfully. Press Ctrl+C to stop the server, run npm install, then try node server.js again.
If you see "address already in use", another process is using port 3000. Close any other running servers or apps on that port and try again.
Make sure the URL in your browser is exactly http://localhost:3000 with no trailing slash or extra path.
help me get my Express server running on localhost:3000

Switch back to your terminal and press Ctrl+C to stop the server.

Your Express server works locally. In the next step, you'll write a Dockerfile to package it into a container that can run on any machine.

Write a Dockerfile and Build Your First Image

Your Express app is up and returning JSON in the browser. That's a solid first step.

There's a catch, though. Your app only works because your Mac has Node.js installed. Send your project folder to someone who doesn't have Node.js, and it won't run. A Dockerfile solves this by packaging your app with its own Node.js runtime into a portable Docker image that runs on any machine.

In this step, get ready to:

Write a Dockerfile to package your Express app with Node.js.
Create a .dockerignore to keep unnecessary files out of the image.
Build your first Docker image and verify it exists.

Write your Dockerfile

A Dockerfile is a plain text file that lists every instruction Docker needs to build an image. Each instruction creates a layer, like stacking building blocks on top of each other.

In VS Code, create a new file in the my-docker-app folder called Dockerfile (no file extension).
Paste the following code into Dockerfile:

# Use a lightweight Node.js base image
FROM node:24-alpine

# Set the working directory inside the container
WORKDIR /app

# Copy all project files into the container
COPY . .

# Install only production dependencies
RUN npm install --omit=dev

# Document the port the app listens on
EXPOSE 3000

# Start the server when the container runs
CMD ["node", "server.js"]

What does each instruction do?

FROM node:24-alpine starts from a pre-built image that already has Node.js installed. Alpine is a tiny Linux distribution (~5 MB), so the final image stays small.
WORKDIR /app creates a folder called /app inside the container and makes it the current directory for every instruction that follows.
COPY . . copies everything from your project folder on your Mac into the container's /app directory.
RUN npm install --omit=dev installs your dependencies inside the container. The --omit=dev flag skips development-only packages to keep the image lean.
EXPOSE 3000 documents that the app listens on port 3000. It doesn't open the port by itself, but it tells anyone reading the Dockerfile which port to map.
CMD ["node", "server.js"] is the command Docker runs when the container starts. This launches your Express server.

Save Dockerfile.
Confirm Dockerfile appears in the VS Code Explorer sidebar alongside server.js and package.json.

Don't see the Dockerfile in Explorer?

Make sure the file is named exactly Dockerfile with a capital D and no extension. Not Dockerfile.txt, not dockerfile.
Check that it is inside the my-docker-app folder, not one level above it.
help me find why my Dockerfile isn't showing up in VS Code

When Docker runs COPY . ., it copies everything in your project folder into the image by default. That includes node_modules, which you don't need since the Dockerfile already installs fresh dependencies with npm install.

Create another new file in the my-docker-app folder called .dockerignore.
Paste the following into .dockerignore:

# Dependencies (installed fresh inside the container)
node_modules
npm-debug.log

# Docker config (not needed inside the image)
Dockerfile
.dockerignore

# Version control
.git

Why exclude these files?

Your local node_modules folder can be hundreds of megabytes. Copying it into the image would bloat the build and potentially introduce platform-specific binaries that won't work inside the container.

The Dockerfile itself, .dockerignore, and .git are build tools, not application code. Keeping them out makes the image smaller and cleaner.

Save .dockerignore.
Confirm both Dockerfile and .dockerignore appear in the Explorer sidebar.

✔️ Awesome, I've got everything!

Great. Make sure you've saved both Dockerfile and .dockerignore.

ⓧ I'd like to double check the full code

Here is the full Dockerfile:

# Use a lightweight Node.js base image
FROM node:24-alpine

# Set the working directory inside the container
WORKDIR /app

# Copy all project files into the container
COPY . .

# Install only production dependencies
RUN npm install --omit=dev

# Document the port the app listens on
EXPOSE 3000

# Start the server when the container runs
CMD ["node", "server.js"]

And the full .dockerignore:

# Dependencies (installed fresh inside the container)
node_modules
npm-debug.log

# Docker config (not needed inside the image)
Dockerfile
.dockerignore

# Version control
.git

Build your first Docker image

Your Dockerfile is a recipe. Now you need to tell Docker to follow it and produce an image. Before you can build, Docker Desktop needs to be running.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Docker Desktop and press Enter to open it.
Wait for the Docker engine to start. You will see a green "Engine running" indicator in the bottom-left corner of the Docker Desktop window.

Why does Docker Desktop need to be running?

Docker Desktop runs the Docker engine in the background. The docker command in your terminal talks to this engine. Without it running, any docker command will fail.

Switch back to your terminal in VS Code.
Make sure you are inside the my-docker-app folder (this is where your Dockerfile lives).
Build your Docker image by running this command:

docker build -t my-node-app .

What does this command do?

docker build tells Docker to read your Dockerfile and execute each instruction to produce an image.
-t my-node-app tags the image with the name my-node-app so you can refer to it later instead of using a long ID.
. (the dot at the end) tells Docker to use the current directory as the build context. Docker looks here for the Dockerfile and for files to COPY.

The first build takes a minute or two because Docker needs to download the node:24-alpine base image. You will see output for each step in your Dockerfile as Docker processes it.

Seeing "Cannot connect to the Docker daemon"?

This means Docker Desktop isn't running yet. Open it and wait for the green "Engine running" indicator before retrying the command.
If Docker Desktop shows an error on startup, try restarting it completely by quitting and reopening the application.
help me fix the Docker daemon connection error

Before you check the result, what do you think docker images will show you? How many images do you expect to see?

Verify your image was built by running:

docker images

You should see my-node-app listed in the output with its size displayed. You will also see node listed separately. That's the base image Docker downloaded to build yours on top of.

Don't see my-node-app in the list?

Scroll up in your terminal to check if the docker build command showed any errors. A typo in your Dockerfile will cause the build to fail.
Make sure you ran the build command from inside the my-docker-app folder. Docker looks for a file called Dockerfile in the current directory.
Check that your file is named exactly Dockerfile with a capital D and no file extension.
help me fix my Docker build

Your app is now frozen inside a Docker image, ready to run anywhere. Next up, you will turn that image into a running container and visit your app in the browser, served entirely from inside Docker.

Run Your Container and See It Live

Your Docker image is built and ready. Now it's time to turn that blueprint into a live, running container you can visit in your browser.

A container is an isolated process with its own filesystem and network. Its ports are invisible to your Mac by default, so you need to explicitly map them before your browser can reach the app inside.

In this step, get ready to:

Run a container from your Docker image with port mapping.
Visit your running app at localhost:3000 to confirm it works.
Manage your container with docker ps, docker logs, and docker stop.

Run the container with port mapping

The docker run command creates a container from an image and starts it. You need flags to run it in the background, name it, and map its internal port to your Mac.

Start a new container from your my-node-app image by running this command:

docker run -d -p 127.0.0.1:3000:3000 --name my-app my-node-app

Your terminal prints a long string of characters. This is your container's unique ID.

What do these flags do?

-d runs the container in detached mode (in the background), so your terminal stays free for more commands.
-p 127.0.0.1:3000:3000 maps port 3000 inside the container to port 3000 on your Mac. Without this, your browser cannot reach the app.
--name my-app gives the container a human-readable name instead of a random one.
my-node-app at the end tells Docker which image to create the container from.

Seeing a port conflict?

If you see an error mentioning port 3000 already being in use, your local Express server from Step 1 might still be running.
Switch to the terminal where you ran node server.js and press Ctrl+C to stop it.
Then run the docker run command again.

Help me fix a Docker port conflict on port 3000.

Visit your app in the browser

Before you open your browser, what do you expect to see at http://localhost:3000? Think about what your Express server sends back.

Open your browser and navigate to http://localhost:3000.

You should see {"message":"Hello from Docker!"} in the browser. This is the same response from Step 1, but now it's being served from inside a Docker container.

How is this different from Step 1?

In Step 1, your Mac's own Node.js installation ran the server. Now, the server is running inside a container that has its own copy of Node.js. Your Mac could have a completely different version of Node.js, or none at all, and the container would still work.

Explore your running container

Docker provides commands to inspect and manage running containers. Let's try the three most common ones.

Check which containers are currently running by using this command:

docker ps

You should see my-app listed in the output along with its status, port mapping, and the image it was created from.

View the output your server printed at startup by running:

docker logs my-app

You should see Server running on port 3000 in the output. This is the console.log from your server.js file, captured by Docker.

Stop the running container by running:

docker stop my-app

Docker prints my-app back to the terminal to confirm the container has stopped.

Confirm the container is no longer running by running:

docker ps

The list is now empty. Your container has stopped and is no longer serving traffic.

What happens when you stop a container?

Stopping a container shuts down the process inside it, but the container itself still exists on disk. Think of it like shutting down a laptop instead of throwing it away. The container and all its data are still there, ready to be started again.

Container not showing in docker ps?

Make sure Docker Desktop is still running. Check for the Docker whale icon in your menu bar.
If you see an error mentioning the Docker daemon, restart Docker Desktop and try again.

Help me troubleshoot why my Docker container isn't showing up.

Your container runs, responds to requests, and you know how to inspect and stop it. Next up, you'll change your code and discover why Docker rebuilds can be frustratingly slow.

Change Your Code and Hit the Rebuild Problem

You've proven your app works inside a Docker container, served from an isolated environment with its own filesystem and network. The next question is: what happens when you need to change your code?

In development, code changes are constant. Every small edit means rebuilding the Docker image. There is a hidden cost in the current Dockerfile that makes every rebuild slower than it needs to be. You'll experience this problem firsthand in this step.

In this step, get ready to:

Stop and remove the old container.
Change the greeting message in server.js.
Rebuild the image and observe the slow-rebuild problem.

Stop and remove the old container

You stopped the container at the end of the previous step, but it is still registered with Docker. You need to remove it before you can create a new container with the same name.

Remove the old container by running these commands:

docker stop my-app
docker rm my-app

What do these commands do?

docker stop my-app sends a shutdown signal to the container. If the container is already stopped, this command simply returns the container name.
docker rm my-app deletes the container record entirely. Your image is still available for creating new containers.

Confirm the container is gone by running:

docker ps -a

You should not see my-app in the output. The container has been fully removed.

Getting an error about 'no such container'?

This means the container was already removed. You can safely continue to the next substep.

Why am I getting a container error when I try to stop or remove my Docker container?

Change the greeting message

Time to make a small code change. You'll update the greeting message so you can rebuild the image and see how Docker handles the change.

Switch back to VS Code and open server.js.
Find this line inside the app.get route:

  res.json({ message: 'Hello from Docker!' });

Change 'Hello from Docker!' to 'Hello from Docker! (updated)', so the line looks like this:

  res.json({ message: 'Hello from Docker! (updated)' });

Save server.js.

Rebuild the image and watch what happens

Before you rebuild, think about what you expect to happen. You only changed server.js. You did not touch package.json or add any new dependencies. Do you think npm install will need to run again?

Switch back to your terminal and rebuild the image by running:

docker build -t my-node-app .

Watch the build output carefully. Each step shows either CACHED (reused from the previous build) or runs fresh.

You'll see that the RUN npm install --omit=dev step runs again from scratch. There is no CACHED label on it, even though your dependencies did not change at all. This is the slow-rebuild problem.

Why did npm install run again?

Look at the Dockerfile. The COPY . . line copies your entire project into the image, including server.js. When you changed server.js, Docker detected that the COPY . . layer changed.

Docker caches layers in order. When one layer changes, every layer after it must re-run. Since RUN npm install --omit=dev comes after COPY . ., Docker has to run it again from scratch.

In a real project with hundreds of dependencies, this wasted reinstall could take minutes every time you change a single line of code.

Now you've seen the slow-rebuild problem firsthand. In the next step, you'll fix it by restructuring the Dockerfile so that dependency installation is cached separately from your source code.

Optimize with Layer Caching

In the last step, you experienced the slow-rebuild problem firsthand. Every rebuild ran npm install from scratch, even though you only changed one line of code.

Docker caches each step of your build as a separate layer. By restructuring your Dockerfile, you can make Docker skip npm install entirely when only your source code changes.

In this step, get ready to:

Restructure the Dockerfile to install dependencies before copying source code.
Rebuild the image and confirm that code-only changes no longer trigger a full reinstall.

Restructure the Dockerfile for layer caching

Docker processes each instruction in your Dockerfile as a separate layer. If a layer and everything above it has not changed, Docker reuses the cached version instead of rebuilding it.

Right now, COPY . . copies everything (including your source code) before npm install runs. Any code change invalidates that layer and forces a full reinstall.

In VS Code, open your Dockerfile. It currently looks like this:

FROM node:24-alpine
WORKDIR /app
COPY . .
RUN npm install --omit=dev
EXPOSE 3000
CMD ["node", "server.js"]

Replace the entire contents of Dockerfile with this updated version:

# Use a lightweight Node.js base image
FROM node:24-alpine

# Set the working directory inside the container
WORKDIR /app

# Copy dependency files first (layer caching optimization)
COPY package.json package-lock.json ./

# Install production dependencies (cached unless package.json changes)
RUN npm install --omit=dev

# Copy the rest of the source code
COPY . .

# Document the port the app listens on
EXPOSE 3000

# Start the server
CMD ["node", "server.js"]

What changed?

The old Dockerfile copied everything with COPY . . as one step, then ran npm install. Any file change invalidated the entire copy layer and forced a reinstall.

The new version splits the copy into two steps. COPY package.json package-lock.json ./ copies only the dependency files. RUN npm install --omit=dev installs them. Then COPY . . copies the source code last.

Now when you change server.js, only the final COPY . . layer is invalidated. The npm install layer stays cached.

Save Dockerfile.
Prime the layer cache by rebuilding the image with this command:

docker build -t my-node-app .

Every step runs fresh because this is the first build with the new Dockerfile structure. You should see each layer complete without a CACHED label.

Build failed?

Check that COPY package.json package-lock.json ./ comes before RUN npm install --omit=dev in your Dockerfile. The order matters.
Make sure package-lock.json exists in your project folder. It was generated when you ran npm install locally in Step 1.
Confirm you still have COPY . . on its own line after the RUN npm install line. Missing this second COPY means your source code never makes it into the image.

Why is my Docker build failing after I restructured the Dockerfile?

✔️ Awesome, I've got everything!

Great. Make sure you have saved your Dockerfile and the build completed successfully.

ⓧ I'd like to double check the full code

Here is the complete Dockerfile at this point:

FROM node:24-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Test the cache with a code change

The cache is now primed. To prove it works, you need to make a code-only change and rebuild. If the optimization worked, Docker will skip the npm install step entirely.

In server.js, find this line:

  res.json({ message: 'Hello from Docker! (updated)' });

Change the message back to the original, so the line looks like this:

  res.json({ message: 'Hello from Docker!' });

Save server.js.

Before you rebuild, think about what you expect to see. You changed server.js but did not touch package.json. Will npm install run again, or will Docker use the cached version?

Rebuild the image by running:

docker build -t my-node-app .

The npm install step now shows CACHED in the build output. The build completes in seconds because Docker skipped the dependency installation entirely.

Why is this so much faster?

Docker checks each layer from top to bottom. Since package.json did not change, the COPY package.json package-lock.json ./ layer is identical to last time. Docker reuses it and every layer that follows from it, including the npm install step.

Only the COPY . . layer at the bottom needs to rebuild because your source code changed. This is the same optimization used in every production Docker setup.

Not seeing CACHED on the npm install step?

Make sure you ran the first build (the priming build) before editing server.js. The cache only works if there is a previous build to cache from.
Check that you only changed server.js and did not accidentally edit package.json. Any change to package.json invalidates the dependency layer.
Verify that COPY package.json package-lock.json ./ is on its own line above RUN npm install --omit=dev in your Dockerfile. The order is critical for caching to work.

Why is my Docker build not caching the npm install layer?

Your Dockerfile is now optimized with layer caching. Fast rebuilds like this are the foundation of every production Docker workflow.

Secret mission

Add a New Route and Environment Variables

Your app works, but every configuration change requires a new image build. Real production apps use environment variables to change behavior at runtime without touching the code or rebuilding. In this mission, you will add a new API route and configure it with environment variables passed into the container.

Clean Up Your Resources

This project runs entirely locally with Docker Desktop, so there are no ongoing costs. Decide whether to keep your resources, pause them to come back later, or delete them entirely.

Resources you used:

Docker container my-app (uses memory only while running).
Docker image my-node-app (uses disk space).
Project folder my-docker-app on your Desktop (source code, node_modules, Dockerfile).

Keep everything running

No action needed. Choose this if you are still actively building on this project or plan to keep experimenting with Docker containers.

Your Docker images stay on your Mac and only use disk space.
Stopped containers use a tiny amount of disk space for their metadata. Running containers use memory.
None of these resources cost money. Docker Desktop is free for personal use.

Pause - I'll come back to this later

Stop any running containers to free up memory. Your images and project files stay on your Mac so you can pick up where you left off.

Stop the running container by running:

docker stop my-app

Your image my-node-app stays cached. Next time, you can start the container again with docker run.

Delete - I don't want to use this again

Remove all project containers, images, and files from your Mac. Follow these steps in order.

Stop and remove the container by running:

docker stop my-app
docker rm my-app

Remove the Docker image by running:

docker rmi my-node-app

Remove any leftover stopped containers and unused images by running:

docker container prune
docker image prune

What do these prune commands do?

Both commands will ask you to confirm with y before deleting anything. docker container prune removes all stopped containers. docker image prune removes unused images that are no longer tagged or referenced by any container.

Delete the project folder from your Desktop. On macOS or Linux, run:

rm -rf ~/Desktop/my-docker-app

On Windows, run:

rmdir /s /q %USERPROFILE%\Desktop\my-docker-app

Nuclear option

If you want to remove all unused Docker containers, images, and build cache from your entire system (not just this project), you can run:

docker system prune -a

This will ask for confirmation before deleting. Only use this if you have no other Docker projects you want to keep.

Nice Work!

You just built a Node.js web server, packaged it into a Docker image, and ran it as a container you can visit in your browser. That is the foundational Docker skill every backend and DevOps job listing asks for.

You've learned how to:

Write a Dockerfile from scratch, build it into a Docker image with docker build, and run it as a live container with docker run and port mapping so your browser could reach the app.
Diagnose the slow-rebuild problem and fix it with Docker layer caching by structuring your Dockerfile to copy dependency files before source code.
Manage the full container lifecycle with docker ps, docker logs, docker stop, and docker rm.
Secret Mission: Configure your container at runtime using environment variables with the -e flag, the same pattern used in production deployments.

Ready to quiz yourself?