Skip to content
Open-AudIT. What's on your network?

Deploying Open-AudIT with Docker Compose

Community Contributor · 2025-10-22 · Tutorials

Open-AudIT Community ships with container support in the source code itself. There is no published image on Docker Hub. Instead, the GitHub repository includes a compose.yml and Containerfiles that build two containers locally: an Apache/PHP web container and a MariaDB database container.

This guide walks through that official setup with Docker. The upstream project documents it in CONTAINER.md using Podman; the two are interchangeable here, so use whichever your host runs.

Prerequisites

  • Git
  • Docker Engine with Compose v2 (or Podman with podman-compose)
  • A host with network access to the subnets you want to audit

1. Clone the source

The compose file ships with the source, so you do not write your own:

git clone https://github.com/Opmantek/open-audit.git open-audit
cd open-audit

All remaining steps run from the open-audit directory.

2. Set folder permissions

The web container mounts the cloned source and needs to write to a few directories:

chmod 0777 ./app/Attachments
chmod 0777 ./other/scripts
chmod 0777 ./public/custom_images
chmod 0777 ./writable
find ./writable -type d -exec chmod 0777 {} \;

3. Review the compose file

Open compose.yml before building. The defaults work out of the box, but two things deserve attention:

Change the default passwords. The database credentials appear in both services and must stay in sync: MARIADB_PASSWORD on the database service and database_default_password on the web service (likewise the root password). The database connection settings use the naming Open-AudIT's framework expects:

environment:
  app_baseURL: http://localhost:8087
  database_default_hostname: open-audit-community-database
  database_default_database: openaudit
  database_default_username: openaudit
  database_default_password: openauditpassword
  database_default_port: 3306
  database_default_DBDriver: MySQLi

Set app_baseURL to the address you will actually browse to. The web container publishes port 8087, so for local use that is http://localhost:8087 as above. If you put the site behind a proxy or hostname later, update this value to match.

4. Build and start

docker compose build
docker compose up -d

The database container seeds its schema from other/open-audit.sql on first start. Then install the PHP dependencies inside the web container:

docker exec -it open-audit-community-web sh -c "composer install"

5. Log in

Open http://localhost:8087/index.php in your browser. To stop the stack later, run docker compose down. The database persists in the named database_storage volume, and your attachments and settings live in the cloned source directory.

Optional: TLS with a reverse proxy

For anything beyond local use, terminate TLS in front of the web container:

server {
    listen 443 ssl;
    server_name audit.yourdomain.com;

    ssl_certificate     /etc/ssl/certs/audit.crt;
    ssl_certificate_key /etc/ssl/private/audit.key;

    location / {
        proxy_pass         http://127.0.0.1:8087;
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Remember to set app_baseURL in compose.yml to the public URL and rebuild.

Backups

Dump the database from the database container on a schedule:

docker exec open-audit-community-database \
  mariadb-dump -u openaudit -p<your-password> openaudit \
  | gzip > backup_$(date +%Y%m%d).sql.gz

Back up the cloned source directory too. It holds your attachments, custom images and writable data.

Updating

Because the containers are built from the source you cloned, updating means pulling the latest code and rebuilding:

git pull
docker compose build
docker compose up -d
docker exec -it open-audit-community-web sh -c "composer install"

Network discovery notes

The web container image includes Nmap and SNMP tooling, and a cron task inside the container runs scheduled discoveries. The stack uses a standard bridge network, so make sure the Docker host can reach the subnets you want to audit. Discovery of the host's own subnet works normally; scanning behaviour across routed networks depends on your environment, so verify reachability from inside the container if a discovery comes back empty.


The compose file and Containerfiles are maintained in the source tree, so treat CONTAINER.md as the canonical reference if anything here drifts. Improvements are welcome. Open a pull request on GitHub or share your setup on the community forum.

Back to the blog