Skip to content

Docker Environment

The Docker-based setup is tailored per project to allow full flexibility and control during both local development and production deployment. Each core service (PHP, Nginx, MySQL) is containerized with its own Dockerfile and configuration to ensure version control, customization, and stability.

Folder structure

project/
├── devops/
│   ├── dev/
│   │   ├── mysql/
│   │   │   ├── Dockerfile
│   │   │   └── my.cnf
│   │   ├── nginx/
│   │   │   ├── certs/
│   │   │   │   ├── site-local.pem
│   │   │   │   └── site-local-key.pem
│   │   │   ├── Dockerfile
│   │   │   └── default.conf
│   │   ├── php/
│   │   │   ├── Dockerfile
│   │   │   └── php.ini
│   │   └── node/
│   │       └── Dockerfile
│   │
│   └── prod/
│       ├── bash/
│       │   └── deployment-script.sh
│       ├── mysql/
│       │   ├── Dockerfile
│       │   └── my.cnf
│       ├── nginx/
│       │   ├── Dockerfile
│       │   └── default.conf
│       ├── php/
│       │   ├── Dockerfile
│       │   └── php.ini
│       └── node/
│           └── Dockerfile
├── docker-compose.yml
├── docker-compose.override.yml
└── .env

Environment separation: dev vs prod

The environment is structured with two clearly separated layers:

Environment Purpose Path
dev Local development devops/dev/
prod Production deployment devops/prod/

This separation provides:

  • Safe customization during development without affecting production containers.
  • Each service (php, nginx, mysql, node, etc.) has its own Dockerfile for both dev and prod.
  • Developers can tweak local files (e.g., add tools, debugging utilities).
  • Production images remain stable, minimal, and optimized for live deployment.

Services

Service Description Doc
PHP Backend application server PHP Container
Nginx Web server and reverse proxy Nginx Container
MariaDB Relational database MariaDB
Node.js Asset compilation (watch mode) Node.js Container

See Configuration for environment variables, build arguments, and local overrides.

Deployment model

Each deployment creates a new timestamped release folder. Docker containers always mount a symlinked current/ directory rather than the release folder directly. The deployment script updates the symlink atomically after a successful build, so the running containers never need to be restarted to pick up a new release.

This separation means:

  • Container restarts do not affect the active deployment.
  • Rolling back is a symlink swap — no container rebuild required.
  • Deployment logic is fully isolated from runtime.