Load and Run the Docker Container

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.

Prerequisites

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.

Step 1: Run the setup script

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:

  • (Optional) A DNS A record for your Docker server, in case you want to generate a free TLS certificate via Let's Encrypt.
  • SMTP configuration for email notifications. This can be skipped, but we recommend configuring your instance for email notifications and password resets at some point. Our guide to do so manually later on is here.

Headless / unattended installation

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:

  • License key — when using --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.
  • Domain confirmation — if neither 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.
  • SMTP setup — prompted interactively; answer n to skip during install and configure SMTP later via the mail server guide.

Bring your own certificates

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.

Secrets and sensitive configuration

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.

Volume reference

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.

Customising the Compose configuration

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.

Step 2: Start the stack

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

Startup order

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.

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.

Seven Strategies To Differentiate Your Cybersecurity Consultancy

You don’t need to reinvent the wheel to stand out from other cybersecurity consultancies. Often, it's about doing the simple things better, and clearly communicating what sets you apart.

  • Tell your story better
  • Improve your testimonials and case studies
  • Build strategic partnerships

Loading form...

Your email is kept private. We don't do the spam thing.