Chapter 19: Environment & Build

Learn how to configure environments, build production-ready apps, and containerize with Docker.

Env Variables

Production Build

Docker Basics

Security

Quiz

Environment Variables

Environment variables are like spy instructions. They are secret, separate from the mission briefing (your code), and change depending on the mission (development vs production). You would never print classified info in a public newspaper — and you should never hard-code secrets like API keys or passwords in your source code.

Environment variables let you store configuration that changes between environments (development, testing, production) without modifying your code:

Database URLs — Different databases for dev and production
API keys — Secret keys for third-party services
JWT secrets — Keys for signing authentication tokens
Port numbers — Different ports for different environments

.env — Development Environment

# .env (development - on your local machine)
NODE_ENV=development
PORT=3000
DATABASE_URL=sqlite:./dev-database.sqlite
JWT_SECRET=dev-secret-key-not-for-production
API_KEY=sk-dev-12345

# .env.production (production - on the server)
# NODE_ENV=production
# PORT=8080
# DATABASE_URL=postgresql://user:pass@db-server:5432/myapp
# JWT_SECRET=a8f3k9x2m7...very-long-random-string

JavaScript — Using Environment Variables

// Load .env file at the very top of your entry file
require('dotenv').config();

// Access variables with process.env
const PORT = process.env.PORT || 3000;
const DB_URL = process.env.DATABASE_URL;
const SECRET = process.env.JWT_SECRET;

// Use them in your code
app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
});

// Check the environment
if (process.env.NODE_ENV === 'production') {
    // Production-only settings
    app.use(helmet());          // Security headers
    app.use(compression());     // Compress responses
} else {
    // Development-only settings
    app.use(morgan('dev'));     // Log requests
}

NEVER commit .env files to Git! Always add .env to your .gitignore. If you accidentally commit secrets, assume they are compromised and rotate them immediately.

Production Build

Building for production is like packing a suitcase for a trip. During development, your clothes (code) are scattered around your room — easy to find and modify. For the trip (production), you fold everything neatly, remove what you don't need, and compress it all into a compact suitcase. The result is smaller, faster, and ready to go.

Frontend Build (React/Vite)

Terminal — Building a React App

# Development mode: uses a dev server, no optimization
npm run dev

# Production build: creates optimized static files
npm run build
# Output goes to /dist folder:
# dist/
#   ├── index.html         (minified)
#   ├── assets/
#   │   ├── index-abc123.js   (bundled & minified JavaScript)
#   │   └── index-def456.css  (bundled & minified CSS)

# What happens during build:
# 1. Bundling    — All JS files combined into one (or few) files
# 2. Minifying   — Removes whitespace, shortens variable names
# 3. Tree shaking — Removes unused code
# 4. Hashing     — Adds hash to filenames for cache busting

Backend Preparation

package.json — Production Scripts

{
  "scripts": {
    "dev": "nodemon server.js",
    "start": "node server.js",
    "build": "echo 'No build step for backend (Node runs JS directly)'",
    "db:migrate": "sequelize db:migrate",
    "db:seed": "sequelize db:seed:all"
  },
  "dependencies": {
    "express": "^4.18.2",
    "sequelize": "^6.35.0"
  },
  "devDependencies": {
    "nodemon": "^3.0.0"
  }
}

devDependencies are only installed during development. In production, run npm install --production (or npm ci) to skip them and keep the deployment lean.

Docker Basics

Docker is like a shipping container. Before shipping containers, loading cargo onto ships was chaos — different shapes, sizes, and requirements. Shipping containers standardized everything: pack your goods in a container, and it works on any ship, truck, or train. Docker does the same for software: pack your app in a container, and it runs the same on any computer, any server, any cloud.

Docker solves the classic problem: "But it works on my machine!"

Concept	What It Is	Analogy
Image	A blueprint/recipe for your container	A recipe card
Container	A running instance of an image	The dish you cooked from the recipe
Dockerfile	Instructions to build an image	Step-by-step cooking instructions
Docker Compose	Run multiple containers together	A multi-course meal plan

Dockerfile — Backend API

# Use an official Node.js image as the base
FROM node:18-alpine

# Set the working directory inside the container
WORKDIR /app

# Copy package files first (for better caching)
COPY package*.json ./

# Install dependencies (production only)
RUN npm ci --production

# Copy the rest of the application code
COPY . .

# Expose the port the app runs on
EXPOSE 3000

# Command to run when the container starts
CMD ["node", "server.js"]

Terminal — Docker Commands

# Build an image from the Dockerfile
docker build -t my-api .

# Run a container from the image
docker run -p 3000:3000 -d my-api
# -p 3000:3000 = map port 3000 on your machine to port 3000 in the container
# -d = run in background (detached)

# See running containers
docker ps

# View container logs
docker logs <container-id>

# Stop a container
docker stop <container-id>

docker-compose.yml — Multi-Container Setup

version: '3.8'
services:
  api:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://user:pass@db:5432/myapp
      - JWT_SECRET=${JWT_SECRET}
    depends_on:
      - db

  db:
    image: postgres:15-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

With Docker Compose, docker compose up starts your entire stack (API + database) with one command. docker compose down stops everything.

Security Best Practices

Before deploying, make sure your app follows these security practices:

Terminal — Install Security Packages

# Essential security packages
npm install helmet cors express-rate-limit

JavaScript — Security Middleware

const helmet = require('helmet');
const cors = require('cors');
const rateLimit = require('express-rate-limit');

// 1. HELMET — Sets various HTTP security headers
app.use(helmet());
// Prevents: clickjacking, XSS, MIME sniffing, etc.

// 2. CORS — Controls which websites can call your API
app.use(cors({
    origin: 'https://myapp.com',  // Only allow your frontend
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    credentials: true
}));

// 3. RATE LIMITING — Prevent brute force attacks
const limiter = rateLimit({
    windowMs: 15 * 60 * 1000,  // 15 minutes
    max: 100,                   // Max 100 requests per window
    message: 'Too many requests, please try again later'
});
app.use('/api/', limiter);

// Stricter limit for auth routes (prevent password guessing)
const authLimiter = rateLimit({
    windowMs: 15 * 60 * 1000,
    max: 5,  // Only 5 login attempts per 15 minutes
    message: 'Too many login attempts'
});
app.use('/api/auth/login', authLimiter);

// 4. ALWAYS validate and sanitize user input
// Never trust data from the client!

Security Checklist

Category	Do	Don't
Secrets	Use environment variables	Hard-code API keys in source code
Passwords	Hash with bcrypt	Store in plain text
Input	Validate and sanitize everything	Trust user input blindly
Dependencies	Run `npm audit` regularly	Ignore security warnings
HTTPS	Always use HTTPS in production	Serve over plain HTTP
Headers	Use helmet for security headers	Use default Express headers

📝 Chapter 19 Quiz

1. Where should you store sensitive configuration like API keys?

Directly in your JavaScript source code

In a comment at the top of each file

In a .env file (excluded from Git)

In the package.json file

2. What does npm run build do for a React app?

Starts the development server

Creates optimized, minified static files for production

Installs all dependencies

Runs unit tests

3. What is a Dockerfile?

A file with instructions to build a Docker image

A running container

A database configuration file

A Git configuration file

4. What does the helmet package do?

Encrypts all database queries

Hashes passwords automatically

Blocks all incoming requests

Sets HTTP security headers to protect against common attacks

5. Why is rate limiting important for an authentication endpoint?

To make the API respond faster

To reduce database size

To prevent brute force password guessing attacks

To limit the number of registered users

← Chapter 18: Git & GitHub Chapter 20: Deploy to Production →