Deploying the Commercial Edition

The commercial edition of Scanopy is the standard server, unlocked by a license key, for customers on a commercial plan. This guide covers only what differs from the standard self-hosted install — see Installing Scanopy (Self-Hosted) for requirements, verifying the install, and accessing the UI.

What's different

The commercial deployment is identical to the community deployment except for one thing: the server process reads a license key from the SCANOPY_LICENSE_KEY environment variable. Both editions run the same image, ghcr.io/scanopy/scanopy/server:latest; the key is what enables commercial mode at startup.

There is no license file to create or place anywhere. The key is a signed token verified offline at startup — nothing to import, and no outbound call to a licensing server. Anywhere you can set an environment variable for the server process — Docker Compose, a systemd unit, your shell — is a valid place to put it.

A key that is expired or fails verification puts the server into a read-only locked state until it is replaced. The bundled docker-compose.commercial.yml fails fast if SCANOPY_LICENSE_KEY is unset, so a missing key gives you a clear error at startup rather than a server that quietly runs as the community edition.

The steps below cover the Docker Compose deployment. Running the server natively instead? Skip to Without Docker.

1. Download the compose file

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.commercial.yml

2. Set your license key

Your license key comes with your commercial plan. If you don't have one, contact [email protected].

Create a .env file next to the compose file:

SCANOPY_LICENSE_KEY=your-license-key-here

Docker Compose loads .env automatically. Alternatively, export SCANOPY_LICENSE_KEY in your shell before starting.

3. Start Scanopy

docker compose -f docker-compose.commercial.yml up -d

The rest of the flow — verifying the containers are running and accessing the UI — is the same as the standard install.

Without Docker

If you run the server natively — the self-contained binary under systemd rather than a container — nothing about licensing changes. Set SCANOPY_LICENSE_KEY in the environment of the server process, exactly as you set SCANOPY_DATABASE_URL. See Running Without Docker for the full native install.

The recommended place is the EnvironmentFile your unit already reads, so the key stays out of the unit file and off the process command line:

# /etc/scanopy/server.env
SCANOPY_LICENSE_KEY=your-license-key-here
SCANOPY_DATABASE_URL=postgresql://scanopy:your-password@localhost:5432/scanopy

sudo chmod 600 /etc/scanopy/server.env
sudo systemctl restart scanopy-server

The server also loads a .env file from its working directory at startup, so /opt/scanopy/.env works too. EnvironmentFile= is the better default: it doesn't depend on which directory the service happens to start in.

The fail-fast check on a missing key belongs to the compose file, not the server. A native server started without SCANOPY_LICENSE_KEY runs as the free community edition rather than refusing to start — so verify after any change to the unit.

Verify the license is active

The public config endpoint reports the deployment type and license state, on Docker and native installs alike:

curl -s http://localhost:60072/api/config | jq '.data | {deployment_type, license_status, license_expiry}'

A licensed server returns "deployment_type": "commercial" and "license_status": "valid". "community" means the key never reached the process — check the environment of the running service. "expired" or "invalid" means it did reach the process but failed verification; the server is locked read-only until the key is replaced.

The integrated daemon

The compose stack includes an integrated daemon, initialized on first start with nothing to configure. It immediately scans your local network: Layer 2 and Layer 3 host discovery, port and service detection, and container discovery through the mounted socket.

To run daemons elsewhere instead, remove the daemon service from the compose file and clear SCANOPY_INTEGRATED_DAEMON_URL on the server service, then point standalone daemons at your server — see Setting Up Daemons.

Recommended: configure SMTP

Scanopy uses email for account recovery, security notifications, and operational alerts. SMTP is optional — the app is fully usable without it (when no email service is configured, new accounts are auto-verified, so users can register and sign in normally) — but we recommend configuring it for any multi-user deployment.

Works without SMTP

• Registration and sign-in work normally.
• You can still invite teammates: the invite screen generates a shareable link you copy and send yourself. SMTP only adds the convenience of having Scanopy email the invite for you.

Requires SMTP

• Password reset — recovery is email-only. Without SMTP, a user who forgets their password has no self-service way back in, so this is the main reason to set it up.
• Security notifications — alerts when a password or email address changes, or an SSO provider is linked or unlinked.
• Operational alerts — warnings when a daemon becomes unreachable or is placed on standby, plus per-scan discovery summaries.

SMTP is configured with a few environment variables on the server service. See SMTP Configuration in the server configuration reference for the full list and an example.

Next steps

• Server Configuration — Configure server settings
• Configuring Single Sign-On (OIDC) — Set up enterprise authentication
• Quick Start — Deploy your first daemon