Dradis Pro runs as a set of Docker containers managed by Docker Compose. This guide walks you through loading the image, configuring your environment, and starting the stack.
Before you begin, make sure the following are in place on your host:
Docker Engine 20.10 or later and the Docker Compose plugin are installed and running. You can verify with:
docker --version docker compose version
A DNS record pointing at your host.
Are you creating a Docker instance where you will migrate over data from an earlier non-Docker VM instance? If so, follow our VM to Docker migration guide instead.
Once you have Docker installed, installing Dradis couldn't be simpler. All you need to do is:
curl -fsSL https://get.dradis.com | /bin/bash
Follow the instructions on-screen and that should get you up and running! The following information will be requested as you set up and configure your instance, so prepare it if you haven't done so beforehand:
What does the installer change on the host? The installer is designed to get a fresh VM from zero to running Dradis with minimal friction. Depending on your environment, it may:
docker group (note: Docker group membership is effectively equivalent to root access — review this against your security policy before deploying to a shared or hardened host).If Docker is already installed and a compose.yaml already exists on the host, the installer will not modify the Docker installation or touch the Compose lifecycle. Teams with an existing Docker infrastructure can bring the Dradis stack into it directly.
The installer supports flags for non-interactive deployment. Download it first so you can pass arguments:
curl -fsSL https://get.dradis.com -o install-dradis.sh bash install-dradis.sh --help
Supported flags include:
--edition [community|paid] — select the Dradis edition.--domain <hostname> — set the hostname. Also accepted via the DRADIS_DOMAIN environment variable.--lets-encrypt — opt in to automatic TLS certificate issuance via Let's Encrypt. Also accepted via the LETS_ENCRYPT_DOMAIN environment variable.A few prompts currently require interactive input even when flags are provided:
--edition paid, the license key must be entered at the prompt. As a workaround, pipe it via stdin or use expect in your automation script.DRADIS_DOMAIN nor LETS_ENCRYPT_DOMAIN is set and --domain is not passed, the installer pauses for input. Set one of those environment variables to skip this.n to skip during install and configure SMTP later via the mail server guide.If your organisation manages its own TLS certificates, you do not need Let's Encrypt. Place your certificate and key in the ssl/ directory before starting the stack:
ssl/ dradis.crt dradis.key
Pass --domain <hostname> without --lets-encrypt and the installer will not install or invoke certbot. The NGINX container will use the certificates you provide. Renewal is your responsibility and does not require any changes to the Dradis stack.
By default, Dradis uses an .env file (referenced via env_file in the Compose configuration) to pass sensitive values into the stack. This includes MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD, RAILS_MASTER_KEY, and SMTP_PASSWORD. The defaults are intentionally empty and must be set before going to production.
If your environment requires secrets to be kept off disk entirely, Docker Compose's native secrets support is a supported alternative. For example, to supply the SMTP password from a file rather than an env var:
services:
app:
image: dradis-pro:latest
environment:
SMTP_PASSWORD_FILE: /run/secrets/smtp_password
secrets:
- smtp_password
secrets:
smtp_password:
file: ./smtp-secret.txt
This approach keeps secrets out of the environment entirely and integrates cleanly with external secrets managers that can write secret files at container start time.
The dradis-credentials volume stores the application's encryption keys (dradis-plugins.key and master.key). These are created on first deploy (or migrated from a VM) and must be preserved across upgrades — they unlock your encrypted data. Back this volume up alongside your database. If this volume is lost, all the encrypted data is also lost. Whether to encrypt it at rest is a host-level decision.
The Dradis stack uses the following named volumes. Volume names are stable within a major release (e.g. all of Dradis 5.x).
Persistent — back these up:
dradis-credentials — application encryption keys.dradis-storage — uploaded files and attachments.dradis-storage-public — public assets (e.g. user avatars).mysql-data — the application database.Transient — safe to discard on upgrade:
dradis-assets — compiled CSS/JS, rebuilt on each deploy.dradis-tmp — temporary files.You can customise the stack using a compose.override.yaml file, which Docker Compose merges automatically with the base compose.yaml. This is the recommended way to make environment-specific changes — such as relocating volumes to a secondary disk — without modifying the base file, which is updated by the upgrade process.
For example, to bind the MySQL data volume to a specific path on the host:
volumes:
mysql-data:
driver: local
driver_opts:
type: none
o: bind
device: /mnt/sdb/mysql-data
Override files are not touched by the upgrade process. Service names, container names, and volume names are stable within a major release, so overrides written for Dradis 5.x will continue to work across 5.x upgrades.
In case you stop your container after deployment, you can start all containers in the background with:
docker compose up -d
The application will be available at https://[your-hostname] once the stack is ready. You can monitor startup progress with:
docker compose logs -f
Container startup order after a host reboot: The Docker daemon restarts containers on boot but does not re-evaluate depends_on ordering between them. Containers can start out of sequence and produce errors until their dependencies are ready. The recommended workaround is a systemd service that brings the stack down and back up cleanly after the Docker daemon starts:
[Unit] Description=Dradis Pro After=docker.service Requires=docker.service [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/home/deployer/dradis ExecStart=/usr/bin/docker compose up -d ExecStop=/usr/bin/docker compose down TimeoutStartSec=0 [Install] WantedBy=multi-user.target
Save as /etc/systemd/system/dradis.service and enable with systemctl enable dradis.service.
Troubleshooting this step: If any container fails to start, check its logs with docker compose logs [service-name] and contact our support team with the relevant output.
Hardening your Dradis host is your responsibility, and depends entirely on your environment, requirements, and preferences. Some optional hardening/configuration is covered in our Customization guide.
Next help article: Activate your Dradis Instance →
Loading form...
Your email is kept private. We don't do the spam thing.