Configuration¶

Environment selection¶

The active environment is controlled by PROJECT_ENV in your .env file. The deployment script reads this value and pulls configuration from the corresponding ./devops/$PROJECT_ENV/ directory:

Directory layout:

devops/
├── local/
│   ├── docker-compose.override.yml
│   └── .env
├── dev/
│   ├── docker-compose.override.yml
│   └── .env
└── prod/
    ├── docker-compose.override.yml
    └── .env

Environment variables and secrets¶

All container names, credentials, and service settings use environment variables. Create a .env file in the project root and fill in the required values before starting the stack.

Sensitive data (Elementor credentials, DB details) are passed using ${VARIABLE_NAME} syntax:

# Example .env entries
DB_ROOT_PASSWORD=secret
DB_NAME=mysite
DB_USER=mysite_user
DB_PASSWORD=secret
ELEMENTOR_EMAIL=you@example.com
ELEMENTOR_LICENSE=xxxx-xxxx-xxxx

Local overrides with docker-compose.override.yml¶

To customize the local environment without touching the base docker-compose.yml, use docker-compose.override.yml. All customizations must be placed inside the respective ./devops/dev/ directories.

Example — mounting dev-specific Dockerfiles, volumes, and certs:

services:
  php:
    build:
      dockerfile: devops/prod/php/Dockerfile
    volumes:
      - ./:/var/www/html

  mariadb:
    build:
      dockerfile: devops/dev/mysql/Dockerfile
    volumes:
      - ./devops/dev/mysql:/var/lib/mysql/data

  nginx:
    build:
      dockerfile: devops/dev/nginx/Dockerfile
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./:/var/www/html
      - ./devops/dev/nginx/certs:/etc/nginx/certs
      - ./devops/dev/nginx/default.conf:/etc/nginx/conf.d/default.conf

Benefits of this approach:

• Keeps the project base clean and environment-agnostic.
• Developers can customize services without affecting teammates.
• Docker images remain reusable across different projects and environments.

Networking¶

Use one shared external network¶

Define a single external Docker network per project (e.g. project-dk-network) and attach all services to it via the override file.

Benefits:

• Predictable DNS between containers
• Stable internal hostnames (e.g. project-dk-mariadb)
• No accidental networks created by override files

Verify DNS resolution from inside a container:

getent hosts <service-name>

Clean restart¶

After changing network definitions or resolving connectivity issues, recreate all containers cleanly:

docker compose down && docker compose up -d

Containers must be fully recreated — not just restarted — for network changes to take effect.