Week 28: Deployment — LAMP/LEMP & Docker

1. The LEMP Stack

LEMP — Linux, Nginx (pronounced "engine-x," the E), MySQL, PHP — is the production version of every local environment built across this course. The one real architectural shift from local development: PHP no longer serves requests directly (as php -S localhost:8000 did in Week 1) — Nginx sits in front, serving static files itself and forwarding only PHP requests to PHP-FPM:

Local (Week 1):    Browser → php -S (handles everything)

Production:        Browser → Nginx → PHP-FPM (only for .php requests)
                                   ↳ serves static assets (CSS/JS/images) directly, no PHP involved

Static assets never touching PHP at all is a meaningful performance difference at scale — Nginx serving a CSS file directly is dramatically cheaper than routing it through a PHP worker process that does nothing but read and return the file unchanged.

2. Nginx + PHP-FPM Configuration

A working Nginx server block for a Laravel application:

server {
    listen 80;
    server_name task-tracker.example.com;
    root /var/www/task-tracker/public; # Laravel's front controller lives here

    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock; # hands off to PHP-FPM, per Week 26
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.(?!well-known).* {
        deny all; # block access to .env, .git, and other dotfiles
    }
}

try_files $uri $uri/ /index.php?$query_string; is what makes Laravel's routing (Week 9) work at all in production — every request that doesn't match a real static file falls through to index.php, Laravel's single entry point, which then dispatches it through the router exactly as it did with php artisan serve locally.

sudo ln -s /etc/nginx/sites-available/task-tracker /etc/nginx/sites-enabled/
sudo nginx -t   # always test config before reloading
sudo systemctl reload nginx

3. Dockerizing Laravel

A multi-stage Dockerfile keeps the final image small — Composer's build-time dependencies never need to ship in the running container:

# Stage 1: install PHP dependencies
FROM composer:2 AS composer-build
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-scripts

# Stage 2: the actual runtime image
FROM php:8.3-fpm-alpine
RUN docker-php-ext-install pdo pdo_mysql

WORKDIR /var/www
COPY --from=composer-build /app/vendor ./vendor
COPY . .

RUN php artisan config:cache && php artisan route:cache

EXPOSE 9000
CMD ["php-fpm"]

COPY --from=composer-build pulls only the resolved vendor/ directory from the first stage — the Composer binary and its own dependencies from stage 1 never end up in the final image at all, keeping it meaningfully smaller. config:cache/route:cache pre-compile Laravel's config and routes into a single optimized file, skipping that work on every request in production.

services:
  app:
    build: .
    volumes:
      - .:/var/www
    depends_on: [db, redis]

  nginx:
    image: nginx:alpine
    ports: ["8000:80"]
    volumes:
      - ./:/var/www
      - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on: [app]

  db:
    image: mysql:8
    environment:
      MYSQL_DATABASE: task_tracker
      MYSQL_ROOT_PASSWORD: secret
    volumes: ["db-data:/var/lib/mysql"]

  redis:
    image: redis:alpine

volumes:
  db-data:

This mirrors production's Nginx + PHP-FPM split from earlier in this lesson, run locally in containers — the same architecture, same request path, testable before it ever touches a real server.

4. Deploying to a VPS

A minimal deploy script pulling together everything from this module — code, cached config, migrations, queue worker, OPcache:

#!/bin/bash
set -e # stop immediately on any failing command

cd /var/www/task-tracker

git pull origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

sudo systemctl restart php8.3-fpm  # clears OPcache -- per Week 26
sudo supervisorctl restart task-tracker-worker:*  # restarts the queue worker -- per Week 16

set -e matters: without it, a failed composer install wouldn't stop the script, and php artisan migrate could run against a half-updated codebase. Restarting PHP-FPM is the OPcache-clearing step flagged in Week 26 — skip it, and the server keeps serving the previous deploy's cached bytecode indefinitely.

[program:task-tracker-worker]
command=php /var/www/task-tracker/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
numprocs=2

Supervisor keeps the queue worker from Week 16 running continuously, restarting it automatically if it crashes — queue:work run manually in a terminal stops the moment that terminal closes, which is exactly wrong for production.

5. Deploying WordPress

WordPress's deployment story is simpler in one respect (no artisan build steps) and requires more discipline in another (theme/plugin file changes need explicit version control, since WordPress itself doesn't enforce it):

# Version-control only your custom theme/plugin, not WordPress core itself
git clone your-repo /var/www/site/wp-content/themes/my-theme
git clone your-portfolio-manager-repo /var/www/site/wp-content/plugins/portfolio-manager

wp core update            # keep WordPress core current
wp plugin update --all    # keep third-party plugins current -- ties directly into Week 25's audits
wp cache flush

A key discipline worth internalizing from this course's structure: WordPress core and third-party plugins are typically not committed to your own repository (they're external dependencies, updated independently, much like Composer packages) — only the custom theme and plugin you actually wrote belong in version control, deployed the same way any other codebase from this course would be.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.