Host and Run a Website inside Docker for Fast, Portable Deploys

In this blog post Host and Run a Website inside Docker for Fast, Portable Deploys we will turn a website into a portable container, run it locally, and take it to production with HTTPS—without drowning in infrastructure complexity.

At a high level, Docker packages your website and its runtime into a lightweight, isolated unit called a container. You build an image once, run it anywhere Docker is available, and get predictable behaviour across laptops, CI, and servers. That makes shipping updates faster, rollbacks safer, and ops simpler.

Why Docker for websites

Containers are not virtual machines. They share the host kernel but isolate processes with Linux namespaces and cgroups. A Docker image is a layered filesystem with your app, its dependencies, and configuration. When you run a container, Docker creates a writable layer on top of the image, sets up networking, and executes your process.

Consistency: One image runs the same way in dev, staging, and prod.
Speed: Incremental layers make builds and pulls fast; start-up times are seconds.
Isolation: Each website or service has its own file system, config, and network.
Portability: Move between clouds or on-prem without refactoring the app.

How containers serve web traffic in practice

Containers talk to the network via virtual bridges. By default, Docker creates a bridge network; containers get private IPs and can reach each other by name. You publish ports (e.g., 8080 on host to 80 in container) so browsers can connect. Persistent data lives in volumes or bind mounts. For production, a reverse proxy (e.g., Caddy, Nginx, Traefik) terminates TLS and routes domains to containers.

Quick start: static site in minutes

Let’s serve a static website with Nginx in Docker using Compose.

1) Create a project

my-site/
├─ site/
│  └─ index.html
├─ nginx.conf
├─ Dockerfile
└─ compose.yaml

2) Minimal content

<!-- site/index.html -->
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Hello from Docker</title>
  </head>
  <body>
    <h1>It works!</h1>
    <p>This site is running inside a Docker container.</p>
  </body>
</html>

3) Nginx configuration

# nginx.conf
server {
  listen 80;
  server_name _;
  root /usr/share/nginx/html;
  index index.html;

  location / {
    try_files $uri $uri/ =404;
  }

  access_log /var/log/nginx/access.log;
  error_log  /var/log/nginx/error.log warn;
}

4) Dockerfile

# Dockerfile
FROM nginx:1.27-alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY site/ /usr/share/nginx/html/

# Basic liveness check
HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD wget -qO- http://localhost/ || exit 1

EXPOSE 80

5) Compose file

# compose.yaml
services:
  web:
    build: .
    ports:
      - "8080:80"   # host:container
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost/"]
      interval: 30s
      timeout: 3s
      retries: 3

6) Run it

docker compose up -d
curl http://localhost:8080
# Open http://localhost:8080 in your browser

Congratulations—your website is now containerised and running locally. Commit this into version control and you’ve captured the full runtime as code.

From laptop to internet with HTTPS

To serve your site publicly, you need a server (VM or bare metal), DNS pointing your domain to the server’s IP, and TLS certificates. A reverse proxy makes this straightforward. Here we’ll use Caddy to automatically fetch and renew Let’s Encrypt certificates and proxy traffic to your container.

1) DNS

Point an A record (e.g., example.com) to your server’s public IP. Wait for DNS to propagate.

2) Compose with Caddy

# compose.yaml (production)
services:
  web:
    build: .
    restart: unless-stopped

  caddy:
    image: caddy:2.8
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    depends_on:
      - web
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

3) Caddy configuration

# Caddyfile
{
  email admin@example.com
}

example.com {
  encode gzip
  reverse_proxy web:80
}

Then deploy:

docker compose pull --quiet
docker compose up -d

Caddy will request and install a TLS certificate automatically. Visit https://example.com to verify.

Dynamic websites and APIs

For dynamic content, put your app in a container and proxy it with the same Caddy setup. Here’s a tiny Node.js example.

App code

// app/server.js
const express = require('express');
const app = express();
const port = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send('Hello from Dockerized Node!');
});

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

{
  "name": "docker-node-demo",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "scripts": { "start": "node server.js" },
  "dependencies": { "express": "^4.19.2" }
}

Dockerfile for the app

# app/Dockerfile
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY . .
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/ || exit 1
CMD ["node", "server.js"]

Compose (app + Caddy)

# compose.yaml
services:
  web:
    build: ./app
    restart: unless-stopped

  caddy:
    image: caddy:2.8
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    depends_on:
      - web
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Keep the same Caddyfile and DNS steps. Your dynamic app is now on the internet with automatic HTTPS.

Operational tips that pay off

Pin versions: Avoid :latest. Use explicit tags (e.g., nginx:1.27-alpine) to make rollbacks deterministic.
Healthchecks: You’ve seen HEALTHCHECK—use it so Compose and orchestrators can restart unhealthy containers.
Config as code: Keep Dockerfiles, Compose, and proxy configs in your repo. Treat changes like code (review, test, deploy).
Logs: Pipe container logs to your platform’s logging (e.g., CloudWatch, Elastic, or systemd-journald). For quick checks: docker logs -f service.
Backups: Anything users upload or databases store must be in volumes with backups and retention policies.
Resource limits: Set CPU and memory limits appropriate to your host to avoid noisy-neighbour issues.
Zero-downtime: Run two replicas behind your proxy and update one at a time (requires a scheduler like Swarm or Kubernetes). For small setups, a brief maintenance window is acceptable.

Security and cost gotchas

Least privilege: Run processes as a non-root user when possible and avoid binding privileged ports from inside the container. Place a reverse proxy in front.
Network exposure: Only publish ports you need. Keep app containers on private networks; let the proxy be the only public entry point.
Secrets: Don’t bake secrets into images. Mount them at runtime (env files with strict permissions or secret stores).
Image hygiene: Use small, well-maintained base images. Update regularly and scan for CVEs in CI.
Autoscaling vs. overprovisioning: Containers start fast; scale to demand rather than oversizing VMs. Measure and right-size to control costs.

Wrapping up

Docker turns websites into portable, testable, and repeatable units. With a few files—Dockerfile, Compose, and a proxy config—you can run locally, deploy to a server, and serve traffic over HTTPS with confidence. Start with a static site, add a reverse proxy, and when you’re ready, layer in your dynamic app. You’ll ship faster, break less, and sleep better.

Discover more from CPI Consulting

Subscribe to get the latest posts sent to your email.