Deploy with pre-built images

This is the fastest way to run BraDypUS in production.
No source code, no build step — Docker pulls the images directly from GitHub Container Registry and starts the application.

Prerequisites

• Docker Desktop (or Docker Engine + Compose plugin on Linux)

1. Download the Compose file

curl -O https://raw.githubusercontent.com/lad-sapienza/BraDypUS/v5/bradypus.yml

Or create it manually — paste the content from bradypus.yml.

2. Pull the images

docker compose -f bradypus.yml pull

This downloads two images:

Image	Purpose
ghcr.io/lad-sapienza/bdus-api	PHP 8.2 + Apache backend
ghcr.io/lad-sapienza/bdus-app	Vue 3 SPA served by Nginx

3. Start the application

docker compose -f bradypus.yml up -d

The application is now available at http://localhost.

4. Create your first application

With BRADYPUS_ALLOW_NEW_APP enabled you can use the new-app wizard. Edit bradypus.yml to set it temporarily:

environment:
  - BRADYPUS_ALLOW_NEW_APP=1

Then restart: docker compose -f bradypus.yml up -d

Follow the Create application guide to complete the setup.

Pinning a specific version

By default, latest is used. To pin to a specific release:

BDUS_VERSION=5.0.3 docker compose -f bradypus.yml up -d

Updating

Pull the new images and restart:

docker compose -f bradypus.yml pull
docker compose -f bradypus.yml up -d

Data in the projects_data volume is never affected by updates.

Environment variables

Variable	Default	Description
BRADYPUS_DEBUG	0	Set to 1 for debug output
BRADYPUS_ALLOW_NEW_APP	0	Set to 1 to enable the new-app wizard
BDUS_VERSION	latest	Image tag to pull (5.0.3, 5.0, 5, …)
BDUS_PORT	80	Host port (or host:port to bind to a specific interface)

Examples:

# Run on port 8090
BDUS_PORT=8090 docker compose -f bradypus.yml up -d

# Bind to localhost only — ideal behind a reverse proxy (Apache, Nginx, Caddy)
BDUS_PORT=127.0.0.1:8090 docker compose -f bradypus.yml up -d

Data persistence

All application data (SQLite databases, uploaded files, configuration, backups) is stored in a Docker named volume called projects_data. Data survives container restarts, image updates, and docker compose down.

Where is the data stored?

Named volumes are managed by Docker, not stored in a predictable fixed path. To find the exact location on disk:

docker volume inspect $(docker volume ls -q | grep projects_data)

Look for the Mountpoint field in the output, e.g.:

"Mountpoint": "/var/lib/docker/volumes/bradypus_projects_data/_data"

On Docker Desktop (Mac / Windows) volumes live inside the Docker VM and are not directly accessible from the host filesystem — use the commands below instead.

Listing files in the volume

docker run --rm -v projects_data:/data alpine ls /data

Backup

docker run --rm \
  -v projects_data:/data \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/bradypus-backup.tar.gz -C /data .

This creates bradypus-backup.tar.gz in the current directory.

Restore

docker run --rm \
  -v projects_data:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/bradypus-backup.tar.gz -C /data

Bind mount instead of named volume

If you prefer to keep data in a specific host directory (e.g. ./projects), replace the volume entry in bradypus.yml:

# instead of:
volumes:
  - projects_data:/var/www/html/projects

# use:
volumes:
  - ./projects:/var/www/html/projects

Then remove the projects_data: entry from the top-level volumes: section.

Stopping

docker compose -f bradypus.yml down

Data in projects_data is preserved. To also delete the volume (irreversible):

docker compose -f bradypus.yml down -v