Docker LNMP Development Environment Guide: One-Click Local Setup for Multi-Version PHP and Integrated Services - Devuly | Smart Analytics for Developers & Projects

This is a Docker Compose-based LNMP local development platform designed for environment consistency. Its core capabilities include multi-version PHP switching, integrated middleware, and persistent data storage, solving common problems in traditional local setups such as slow installation, severe version conflicts, and difficult migration. Keywords: Docker, LNMP, Docker Compose.

Table of Contents

This Docker LNMP stack meets the need for highly consistent local development

Parameter	Description
Primary Languages	Shell, YAML, Nginx configuration, PHP
Orchestration	Docker Compose
Repository	https://gitee.com/jessedev/docker-lnmp
Stars	Not provided in the original text
Core Dependencies	Docker >= 20.10, Docker Compose >= 2.0
Supported Platforms	macOS / Linux / Windows (WSL2)
Core Components	Nginx, PHP, MySQL, Redis, MongoDB, RabbitMQ, Elasticsearch, Kibana, Nacos

The value of this project is not just “containerizing a single service,” but standardizing a complete development foundation. Developers only need to maintain .env and docker-compose.yml to reuse a unified runtime and avoid manually installing PHP extensions, databases, and message queues.

Compared with a traditional LNMP stack, this solution brings the web server, database, search engine, and configuration center into one orchestration system. The result is lower environment replication cost, more stable team collaboration, and a working setup that new team members can bring online in minutes.

You can reduce the shortest startup path to three steps

git clone https://gitee.com/jessedev/docker-lnmp.git  # Clone the repository
cd docker-lnmp                                        # Enter the project directory
cp .env.example .env                                  # Initialize environment variables
cp docker-compose-example.yml docker-compose.yml      # Generate the orchestration file
docker compose up -d                                  # Start all services in the background
docker compose ps                                     # Check service status

These commands complete source retrieval, configuration initialization, and service startup. Together, they form the minimum closed loop for bringing the environment online.

This environment covers mainstream development scenarios with multi-version PHP and integrated middleware

At the web layer, Nginx provides entry points on ports 80 and 443, and the site root maps to www/ by default. The PHP runtime supports 7.4, 8.0, 8.1, and 8.2, and also includes a Swoole variant. This makes it suitable for parallel development across Laravel, ThinkPHP, Hyperf, and similar projects.

Beyond MySQL 8.0, the data layer also includes MongoDB and Redis. RabbitMQ handles messaging, Elasticsearch and Kibana provide search capabilities, and Nacos covers service governance. This makes the stack more than a basic LNMP environment. It is a locally integrated platform better suited to microservice-oriented development.

You should first understand the responsibility boundaries of each service component

Nginx          -> Unified reverse proxy and static asset entry point
PHP-FPM        -> Executes PHP application code
MySQL/MongoDB  -> Structured and document-oriented data storage
Redis          -> Cache and session storage
RabbitMQ       -> Asynchronous tasks and message decoupling
Elasticsearch  -> Search and aggregation queries
Nacos          -> Configuration center and service governance entry point

This division of responsibility helps you quickly determine whether an issue belongs to the web layer, runtime layer, or middleware layer.

Configuration directory mapping directly determines maintainability

The key to the project structure is not just that it runs, but that configuration, logs, and data are all externalized. conf/ stores service configuration, storage/ stores persistent data, log/ supports troubleshooting, and www/ contains business code.

This directory layout is especially effective for local debugging. For example, if MySQL data becomes corrupted, an Nginx site configuration is incorrect, or PHP-FPM logs show abnormal behavior, you can inspect the relevant files directly on the host machine instead of repeatedly entering containers.

A commonly used Nginx site configuration looks like this

server {
    listen 80;
    server_name example.local;
    root /var/www/example/public;  # Point to the project's public directory
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;  # Prefer static files, then fall back to the front controller
    }

    location ~ \.php$ {
        fastcgi_pass jesse-php8.1-service:9000;  # Forward PHP requests to the target PHP version container
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

This configuration demonstrates the core of the multi-version PHP approach: Nginx connects directly to the corresponding PHP-FPM service by container name.

Middleware initialization is a critical step for environment usability

By default, MySQL root has no password, but you should reset it immediately. MongoDB requires an administrator account. RabbitMQ should have a dedicated management user. Elasticsearch should have its password initialized on first use. Nacos requires its database script to be imported before it can function correctly.

Nacos is especially important because it depends on initialized table structures in MySQL. If you skip database creation and SQL import, the container may still start, but the management UI usually will not work properly. This is a common reason people mistakenly assume the image itself is broken.

You should memorize these common service management commands

docker compose up -d                 # Start all services
docker compose down                  # Stop and remove containers
docker compose restart nginx         # Restart a specific service
docker compose logs -f nginx         # Stream Nginx logs in real time
docker exec -it jesse-nginx-service /bin/bash  # Enter the container for troubleshooting
docker compose ps                    # View orchestration status

These commands cover startup, shutdown, restart, logs, and container access. They form the basic operational command set for daily use.

Centralized environment variables make port conflicts and migration easier to handle

The .env file acts as the entry point for ports, directories, and service parameters. Typical settings include MYSQL_PORT, REDIS_PORT, MONGODB_PORT, ES_HTTP_PORT, and NACOS_PORT. When you encounter a port conflict, do not modify the image first. Update the environment variables instead.

If you run multiple database instances on Windows or Linux desktop environments, the most common conflicts involve ports 80, 3306, and 6379. In that case, update .env and run docker compose up -d again to rebuild the mapping.

A typical port override configuration looks like this

NGINX_HTTP_PORT=8080        # Avoid conflict with local port 80
MYSQL_PORT=3307             # Avoid conflict with local MySQL on 3306
REDIS_PORT=6380             # Preserve the default port for an existing Redis instance
NACOS_PORT=8858             # Avoid conflict with an existing registry or config service

These adjustments do not change the internal container defaults, but they allow you to adapt the stack quickly to your local machine.

You should pay equal attention to permissions and data cleanup strategies

On Linux, insufficient permissions on mounted directories often cause MySQL, Redis, or Elasticsearch to fail during startup. The original solution recommends broadly opening permissions on storage/ and log/, which is acceptable for local development, but you should not copy that approach directly into production.

Data cleanup also requires caution. docker compose down -v and deleting storage/* will completely remove persistent content. That is useful when resetting the environment to a clean state, but it is not appropriate as a recovery action after an accidental mistake. Back up databases and critical configuration first.

Cleanup and repair commands must be executed based on the scenario

chmod -R 777 storage/ log/     # Fix permission issues in local development
docker compose down -v         # Remove containers and volumes
rm -rf storage/* log/*         # Clear persistent data and logs

These commands are suitable for rebuilding the environment, but you must confirm that no required data needs to be preserved before running them.

This project works best as a unified development baseline for PHP teams

If your team maintains multiple PHP projects and depends on Redis, RabbitMQ, Elasticsearch, or Nacos, this Compose-based solution can provide clear benefits. It turns the idea of “environment as documentation” into a concrete directory and configuration structure that is easy to inherit and audit.

Its boundaries are also clear. It currently does not provide a source-level image build process or an extension compilation workflow, and it focuses more on out-of-the-box usability. If you need extra PHP extensions or deep base image customization, you will usually need support from the author or your own maintained Dockerfile system.

FAQ

Is this project suitable for direct production deployment?

It is not recommended to use it in production exactly as-is. It is designed more for local development and integration testing, and its default accounts, permission settings, and directory strategies all need hardening to meet production standards.

How can multiple projects share the same environment?

Place each codebase in a separate subdirectory under www/, then create an independent virtual host for each project under conf/nginx/conf/conf.d/.

What should I check first if the website is inaccessible after the services start?

First, check whether docker compose ps shows healthy services. Then verify whether any ports are in conflict. Finally, inspect docker compose logs -f nginx and the logs of the corresponding PHP container. In most cases, this is enough to quickly locate the issue.

AI Readability Summary

This article reconstructs a Docker Compose-based LNMP development environment that includes Nginx, multi-version PHP, MySQL, MongoDB, Redis, RabbitMQ, Elasticsearch, Kibana, and Nacos. It covers fast startup, configuration essentials, service management, and common troubleshooting practices.