DefectDojo on Ubuntu 24.04 on Azure User Guide
Overview
DefectDojo is the OWASP application vulnerability management platform — a DevSecOps tool that consolidates the findings from your SAST, DAST, SCA, container and infrastructure scanners into a single system of record. It de-duplicates and tracks findings across products, engagements and tests, drives remediation through a configurable workflow, supports JIRA and notification integrations, and exposes a complete REST API so it can sit at the centre of an automated security pipeline. The cloudimg image installs DefectDojo 3.0.100 as the official django-DefectDojo Docker Compose stack and runs it as a systemd service, so a working vulnerability-management platform is online within minutes of launch.
What is included:
- DefectDojo 3.0.100 (BSD-3-Clause) deployed from the official
django-DefectDojoDocker Compose stack, pinned to the 3.0.100 published images so the image never silently upgrades at build time - Docker Engine (Docker CE) + the Docker Compose plugin, installed from the official Docker package repository
- The DefectDojo Compose stack: the
nginxreverse proxy on port 80, theuwsgiDjango application server, theceleryworkerandcelerybeatasync task services, the one-shotinitializer(runs the database migrations and creates the admin account),postgres(PostgreSQL 18, the primary database) andvalkey(Valkey 9, the Celery broker and cache) - All stateful data — the PostgreSQL database, the Valkey data and the DefectDojo media/uploads — on a dedicated 40 GiB data disk mounted at
/var/lib/defectdojo(Docker's data-root is relocated there), independently resizable and re-provisioned on every VM - A per-VM
adminaccount with a generated password, created at first boot - Two systemd units:
defectdojo.service(a oneshot wrapper arounddocker compose up -d) anddefectdojo-firstboot.service - 24/7 cloudimg support
Prerequisites
An active Azure subscription, an SSH key, and a VNet + subnet. Standard_B4ms (4 vCPU / 16 GB RAM) is the recommended size — comfortable for the DefectDojo stack. NSG inbound rules: allow 22/tcp from your management CIDR for SSH and 80/tcp from the CIDR that needs the DefectDojo web UI and API (add 443/tcp if you enable HTTPS).
Step 1: Connect over SSH
Replace <vm-ip> with the public IP of your VM. The default login user is azureuser.
ssh azureuser@<vm-ip>
Step 2: Confirm the services are active
sudo systemctl is-active docker.service defectdojo.service
docker --version
docker compose version
You should see active printed twice, the Docker Engine version, and the Docker Compose v2 plugin version.

Step 3: Confirm the DefectDojo containers are running
cd /opt/defectdojo && sudo docker compose -f docker-compose.yml -f docker-compose.override.cloudimg.yml --env-file .env ps
You should see the core services — nginx, uwsgi, celeryworker, celerybeat, postgres and valkey — in the Up / running state (the one-shot initializer shows Exited (0) after it has completed the migrations and created the admin account).

Step 4: Confirm the data disk is mounted
All stateful DefectDojo data lives on a dedicated data disk mounted at /var/lib/defectdojo.
findmnt /var/lib/defectdojo
df -h /var/lib/defectdojo
findmnt shows the device backing /var/lib/defectdojo and df confirms the 40 GiB volume.

Step 5: Check the DefectDojo login page
The DefectDojo login page is served unauthenticated through the bundled nginx reverse proxy on port 80 and returns HTTP 200.
curl -s -o /dev/null -w "%{http_code}\n" http://localhost/login
A 200 confirms the web UI is up.
Step 6: Read the per-VM admin credentials
A unique admin password is generated for your instance on its first boot and written to a root-only file.
sudo cat /root/defectdojo-credentials.txt
This file lists defectdojo.url (where to sign in), defectdojo.admin.user (admin) and defectdojo.admin.pass. Store the password somewhere safe.

Step 7: Sign in to the DefectDojo web UI
Browse to http://<vm-ip>/ and sign in with the username admin and the defectdojo.admin.pass from Step 6. The UI and the API are served on port 80 by the bundled nginx reverse proxy.

After signing in you land on the DefectDojo dashboard, which summarises your products, engagements and the current findings posture.

Step 8: Organise your work into products and engagements
DefectDojo models your work as products (the application or system under test), engagements (a period of testing against a product) and tests (the individual scans whose results you import). Create a product, then an engagement within it, then import a scan report to populate findings.

Step 9: Triage findings
The Findings view consolidates every imported vulnerability across your products and engagements, de-duplicated and severity-ranked. From here you triage, accept risk, mark as mitigated or false-positive, and drive remediation.

Step 10: Use the REST API
DefectDojo exposes a complete REST API under /api/v2/. Obtain an API token with your admin credentials, then call any endpoint with the Authorization: Token <token> header.
curl -s -X POST http://<vm-ip>/api/v2/api-token-auth/ \
-H 'Content-Type: application/json' \
-d '{"username":"admin","password":"<password from Step 6>"}'
The response contains a token field. Use it to import scan results, query findings and integrate DefectDojo into your CI/CD pipeline.
Step 11: Manage the stack
The whole stack is managed by the defectdojo.service systemd unit, which wraps docker compose under /opt/defectdojo.
sudo systemctl restart defectdojo.service
sudo systemctl status defectdojo.service --no-pager
To inspect logs for a specific service:
cd /opt/defectdojo && sudo docker compose -f docker-compose.yml -f docker-compose.override.cloudimg.yml --env-file .env logs --tail 50 uwsgi
Enabling HTTPS on your own domain
The image serves plain HTTP on port 80 out of the box. To serve DefectDojo over HTTPS on your own domain, terminate TLS in front of the VM — for example with an Azure Application Gateway or a reverse proxy with a Let's Encrypt certificate — pointing at the VM on port 80, and set DD_ALLOWED_HOSTS to your domain in /opt/defectdojo/.env before restarting defectdojo.service. Add 443/tcp to your NSG inbound rules.
First-boot security model
On the first boot of each VM, defectdojo-firstboot.service runs once and:
- Rotates every per-VM secret in the stack — the Django secret key (
DD_SECRET_KEY), the AES-256 credential encryption key (DD_CREDENTIAL_AES_256_KEY) and the PostgreSQL password - Generates a fresh, strong
adminpassword and initialises the stack on an empty database so theinitializercreates the admin account with that password - Verifies the admin API-token round-trip and writes the credentials to
/root/defectdojo-credentials.txt(root-only, mode 0600)
No shared or default secret and no preexisting login ship in the image.
Support
24/7 technical support is included. Contact cloudimg at support@cloudimg.co.uk for help with deployment, scanner imports and parsers, products and engagements, the findings and de-duplication model, the REST API, JIRA and notification integrations, TLS and backups.
DefectDojo and OWASP are trademarks of the OWASP Foundation. PostgreSQL is a trademark of the PostgreSQL Community Association of Canada. Valkey is a trademark of the Linux Foundation. Docker is a trademark of Docker, Inc. All other product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.