{"id":3630,"date":"2026-10-29T15:30:17","date_gmt":"2026-10-29T07:30:17","guid":{"rendered":"http:\/\/www.tinuo-packagesolutions.com\/blog\/?p=3630"},"modified":"2026-10-29T15:30:17","modified_gmt":"2026-10-29T07:30:17","slug":"how-to-create-a-docker-image-for-an-express-application-46fc-91c899","status":"publish","type":"post","link":"http:\/\/www.tinuo-packagesolutions.com\/blog\/2026\/10\/29\/how-to-create-a-docker-image-for-an-express-application-46fc-91c899\/","title":{"rendered":"How to create a Docker image for an Express application?"},"content":{"rendered":"

Hey folks, if you\u2019re running an Express app as a vendor\u2014like I am, we build and deploy Express-powered tools for clients every day\u2014you know how much of a pain inconsistent environments are. One day it works on your dev machine, the next it\u2019s throwing dependency errors in QA, and production\u2026 well, production\u2019s a whole other mess. That\u2019s where Docker comes in. It\u2019s not some fancy tech toy; it\u2019s the fix for \u201cit works on my machine\u201d that we\u2019ve relied on for years. Today I\u2019m breaking down exactly how to build a Docker image for an Express app, from the basics to the little tricks that save us hours of debugging\u2014no overly complicated jargon, just what actually works for us as an Express app provider. Express<\/a><\/p>\n

<\/p>\n

First, let\u2019s get this straight: I\u2019m not here to teach you Docker 101. I\u2019m assuming you\u2019ve got a working Express app already, right? The kind you\u2019ve tested locally, it listens on a port, maybe uses some npm packages, maybe a tiny bit of middleware, and you\u2019re ready to make it portable. We\u2019ve built dozens of these, so I know the mistakes people make here\u2014like using the wrong base image, or installing unnecessary packages that bloat the image. Let\u2019s skip those.<\/p>\n

Step 1: Set Up the Files You Actually Need (No Junk Allowed)<\/h3>\n

First, go to the root of your Express project. You\u2019ll need two key files, and if you\u2019re skipping any, stop here: a package.json<\/code> and package-lock.json<\/code> (or yarn.lock<\/code> if you use Yarn, but we\u2019re sticking to npm since most devs know it). These are non-negotiable because they tell Docker exactly what dependencies to install.<\/p>\n

Wait, and one more\u2014your Dockerfile. That\u2019s the blueprint for your image. No, you don\u2019t need a docker-compose.yml<\/code> for a simple Express app (we only use that for multi-service setups, like if we pair our Express API with a Redis cache or MongoDB, but that\u2019s beyond this guide). Also, delete any node_modules<\/code> folder right now. Do it. Docker doesn\u2019t need local node_modules because we\u2019ll install them inside the container, and having local ones can cause version mismatches. I\u2019ve seen new devs waste 2 hours because they forgot that. Trust me.<\/p>\n

Step 2: Pick the Right Base Image (Size Matters)<\/h3>\n

Okay, next up: choosing a Node.js base image. This is where a lot of people go wrong. You don\u2019t need the biggest, beefiest Node image out of the box. For Express apps, we use slim Alpine images almost every time. Why? Because they\u2019re tiny\u2014way smaller than the full Node image\u2014so they pull faster, deploy faster, and have less attack surface (which is a big deal when we\u2019re shipping our app to clients who care about security).<\/p>\n

Let\u2019s make this concrete. When you pull a Node image, you\u2019ll see tags like node:20-alpine<\/code>, node:20-slim<\/code>, node:20<\/code>. We use node:20-alpine<\/code> right now because it\u2019s the sweet spot. It\u2019s based on Alpine Linux, which is super lightweight, and it has everything Node needs\u2014no extra fluff. If you need something with a few more system libraries (maybe if you\u2019re using a native Node module that needs some OS-level packages), you could use node:20-slim<\/code>, but stick to Alpine first. That\u2019s what we use for 90% of our Express apps.<\/p>\n

Pro tip: Always pin the Node version, not just use node:alpine<\/code>. Like, use node:20.10.0-alpine<\/code> instead of node:alpine<\/code>. If you don\u2019t, when Node 21 drops next month, your Docker build will pull the new version, and if there\u2019s a breaking change, your app will crash. We learned that the hard way with a client last year\u2014their Express app broke in prod because Node 21 changed a middleware method. Pinning versions avoids that. Easy win.<\/p>\n

Step 3: Write the Dockerfile (Line by Line, No Copy-Paste Fluff)<\/h3>\n

Now let\u2019s build the Dockerfile line by line. I\u2019ll show you the exact one we use for every basic Express app, then explain each part so you know why it works, not just what to type.<\/p>\n

Here\u2019s the baseline Dockerfile:<\/p>\n

# Use a pinned, lightweight Node base image\nFROM node:20.10.0-alpine\n\n# Set a working directory inside the container (no more messy paths!)\nWORKDIR \/app\n\n# Copy ONLY package files first\u2014this is a key caching trick\nCOPY package*.json .\/\n\n# Install dependencies\u2014clean install for consistency\nRUN npm ci --only=production\n\n# Copy the rest of your app code (after dependencies, to leverage caching)\nCOPY . .\n\n# Tell Docker what port your app listens on\nEXPOSE 3000\n\n# Command to start your Express app\nCMD ["node", "app.js"]\n<\/code><\/pre>\n
Wait, let\u2019s break that down because that npm ci<\/code> line is important. I see so many people use npm install<\/code> here, and that\u2019s fine for local dev, but for Docker builds, npm ci<\/code> is way better. Why? npm ci<\/code> uses the exact versions listed in package-lock.json<\/code>, so you get the same dependency tree every time. No \u201cthis package updated last night\u201d surprises. We\u2019ve had clients have production outages because npm install<\/code> pulled a minor version that had a bug\u2014never again since we switched to npm ci<\/code>.<\/p>\n
Also, notice we copy the package files before the rest of the app? That\u2019s the caching trick. Docker caches each layer of the image. If you change your app code but don\u2019t touch package.json<\/code>, Docker will skip the dependency install layer entirely, which cuts build time from 10 seconds to 1 second. Game changer when you\u2019re building images 10 times a day for testing.<\/p>\n
Another thing: --only=production<\/code> in npm ci<\/code>. If you have dev dependencies (like testing frameworks, linters, etc.), you don\u2019t need them in the production image. They just add bloat. We had one client\u2019s Docker image go from 300MB to 80MB after adding that flag\u2014insane difference. Just make sure your app doesn\u2019t use any dev dependencies at runtime, which it shouldn\u2019t anyway.<\/p>\n
Quick note on the EXPOSE<\/code> line: That\u2019s just documentation. It tells anyone looking at the Dockerfile that the app uses port 3000. You still have to map the port when you run the container (more on that in a sec). The CMD<\/code> line is the actual command that starts your app\u2014adjust that if your entry point is different, like server.js<\/code> instead of app.js<\/code>.<\/p>\n
Step 4: Build the Image and Test It (Don\u2019t Skip Testing!)<\/h3>\n
Okay, now we\u2019re ready to build the image. Open your terminal, navigate to your project root, and run:<\/p>\n
docker build -t my-express-app .\n<\/code><\/pre>\n
Replace my-express-app<\/code> with a name that makes sense\u2014something your team recognizes, and that your client will know if you\u2019re sharing the image. The -t<\/code> flag tags the image, so you don\u2019t have to reference its random ID later.<\/p>\n
This is where we test it before shipping it to clients, because you don\u2019t want to send a broken image. Run the container with:<\/p>\n
docker run -p 3000:3000 my-express-app\n<\/code><\/pre>\n
Wait, the -p 3000:3000<\/code> part is port mapping. That\u2019s why EXPOSE<\/code> wasn\u2019t enough\u2014you have to bind your local machine\u2019s port (the first number) to the container\u2019s port (the second, which is what your app is listening on). If your app uses port 4000, change that to -p 4000:4000<\/code>.<\/p>\n
Now go to your browser or use curl to hit http:\/\/localhost:3000<\/code> (adjust the port if needed). If your Express app loads, you\u2019re golden. If not, let\u2019s troubleshoot the common issues we run into:<\/p>\n
    \n
  1. Check if the entry point in CMD<\/code> is correct\u2014if you get a \u201ccannot find module app.js\u201d error, that\u2019s probably it.<\/li>\n
  2. Did you forget to copy the app code? Make sure the COPY . .<\/code> line is after the dependency install.<\/li>\n
  3. Are you using a native module? If so, you might need extra system packages (like python3<\/code> or make<\/code>) in the image. For that, add a RUN apk add --no-cache python3 make g++<\/code> line right after the FROM<\/code> line, since Alpine uses apk<\/code> for package management. We only do that if we need it\u2014native modules are rare for Express, but good to know.<\/li>\n<\/ol>\n
    Step 5: Extra Tweaks for Production (We Use These for Client Deployments)<\/h3>\n
    Now, this is the part that turns a test image into something you can ship to a client. We\u2019ve shared basic images with clients, but adding these small tweaks makes them production-ready and way more reliable:<\/p>\n