Configuration

All configuration lives in .env, in the directory that holds docker-compose.yml. docker/generate-env.sh creates it from .env.self-hosted.example, which documents every variable. Docker Compose reads .env to fill in docker-compose.yml, and passes it to the app container as its environment.

Editing .env

• An empty value means the setting is not set.
• ${NAME} refers to another variable. For example, NEXTAUTH_URL=https://${APP_HOST} follows APP_HOST, so a hostname only needs to change in one place.
• Wrap values that contain $, # or spaces in single quotes, for example SMTP_PASSWORD='p@ss#word$1'. The setup script does this for the administrator password and the SMTP credentials it writes.
• Flags take the values true or false.

Applying Changes

After editing .env, recreate the containers whose settings changed:

docker compose --profile tls up -d   # with the bundled Caddy
cd /opt/vulnsy && sudo docker compose up -d                 # with your own reverse proxy

docker compose restart is not enough: it restarts the containers with the environment they were created with.

In the tables below, Default is the value that generate-env.sh writes, and After install says whether you can change the setting later.

Edition and Image

Hostnames

Published Ports

With the bundled Caddy, only ports 80 and 443 need to be reachable. Change BIND_ADDRESS to 0.0.0.0, or to one of the server's addresses, only when your reverse proxy runs on another machine.

Secrets

Three secrets cannot change without consequences. The same applies when you restore the database with a different .env:

PostgreSQL

Changing the Database Password

PostgreSQL reads POSTGRES_PASSWORD only when it creates its data volume, on the first start. To change the password later, change it in PostgreSQL first:

docker compose exec postgres psql -U vulnsy -d postgres -c '\password vulnsy'

Enter a new password made of letters and digits only. Then set the same value as POSTGRES_PASSWORD in .env, and run docker compose up -d. If you changed POSTGRES_USER before the first start, use that name instead of vulnsy.

Object Storage

Storage Options

Bundled object storage (the default). The bundled image is Silo, a maintained MinIO-compatible fork (the MINIO_* variable names above are kept for familiarity). Files are kept in the vulnsy_minio-data Docker volume. The app connects to MinIO over the internal network (S3_ENDPOINT), and signs download links for the files host (S3_PUBLIC_ENDPOINT), which browsers can reach. The files host must be a plain reverse proxy of MinIO, at the root of its own hostname, that passes the Host header through unchanged: a signature covers the hostname and the path, so rewriting either one breaks every link.

Another S3-compatible store. To keep files in an S3-compatible service that you already run:

1. Create a bucket and credentials for Vulnsy in that store.
2. Set S3_ENDPOINT to the store's S3 API URL as the server reaches it, and S3_PUBLIC_ENDPOINT to the URL at which your users' browsers reach it. The two are often the same.
3. Set S3_BUCKET_NAME, AWS_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for that store.
4. Run docker compose up -d.

Vulnsy uses path-style requests, with the bucket name in the URL path, so the store must support them. If you switch an existing installation, first copy every object from the old bucket to the new one, keeping the object names. The bundled MinIO still starts, because the app depends on it, but it no longer receives files.

Vulnsy does not request server-side encryption from an S3-compatible store. For encryption at rest, encrypt the server's disk or enable encryption in the store.

Email (SMTP)

SMTP Options

Vulnsy sends account emails through this server: sign-in details for new users and temporary passwords. Client portal and disclosure emails use it as well, unless an administrator sets up a different SMTP server in the app under Admin > Email > Delivery. That server then takes precedence for those emails.

The app's log shows the email settings in use, in a line such as:

Email: SMTP smtp.example.com:587 (STARTTLS if offered, authenticated), from vulnsy@example.com

First Administrator

Vulnsy reads these only on the first start, while the database is still empty. Two optional variables are read at the same time. They are included (left blank) in .env.self-hosted.example, so copy the value into .env before the first start if you want them. generate-env.sh does not set these two, so add them by hand:

License

Authentication

AI

AI Options

The AI assistant must be included in your license. An administrator chooses how it runs under Admin > Organization > AI Assistant. Vulnsy-managed AI is not available in the self-hosted edition, which leaves two modes:

• Your OpenRouter key. Requests go to OpenRouter with your own API key, so the server needs outbound HTTPS access to OpenRouter.
• Your own / local AI endpoint. Any OpenAI-compatible API, such as Ollama or vLLM. Vulnsy calls /chat/completions under the base URL you enter.

By default, an endpoint must use HTTPS on port 443 or 8443, at a public address. For a model server on your own network, set AI_ALLOW_PRIVATE_ENDPOINTS=true and run docker compose up -d app. Vulnsy then also accepts http://, any port, and private addresses, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 and IPv6 unique-local addresses.

Loopback and link-local addresses are always blocked, including localhost, 127.0.0.1 and the cloud metadata address 169.254.169.254. Inside the app container, localhost is the container itself. Instead, use:

• The server's LAN address, when the model server runs on the Docker host, for example http://192.168.1.20:11434/v1. The model server must listen on that address, not only on 127.0.0.1.
• A service name, when the model server runs as another service in the same Compose project, for example http://ollama:11434/v1.

See Provider Modes for how the modes work in the app.