Deploying dpndncY

dpndncY ships as one container image. This page explains what you are deploying and how to choose a method. The step-by-step guides are:

Before you begin: Getting the software (registry, file, or your own registry), Ports and networking (what to open, for the network team), and for the person delivering it, Handing dpndncY to a customer. When something goes wrong: Troubleshooting.

#What you are deploying

                       console host                       API host
                  dpndncy.example.com            api.dpndncy.example.com
                          |                                  |
     browsers ------------+          CLI, CI pipelines, runtime agents
                          |                                  |
                 +--------v----------------------------------v--------+
                 |  container  ghcr.io/dpndncy-sca/platform           |
                 |    :3000  console (web UI)                          |
                 |    :3001  API (also /health and /releases)          |
                 |    scan engines: SCA, SAST, secrets, AI risk, ...   |
                 +----------------------------+------------------------+
                                              |
                                   volume mounted at /app/data
                          (SQLite database, signing secrets, caches)

Four facts decide everything else:

1. Two ports, normally two hostnames. Port 3000 is the web console. Port 3001 is the API that the CLI, CI pipelines and runtime agents call. The console only serves the browser; it does not forward API calls for other clients. A deployment that exposes only the console works for people but not for pipelines. Publish both.
2. One replica. The database is a single SQLite file in /app/data. Run exactly one container per installation. Scaling up means a bigger machine, not more replicas.
3. One volume holds all state. Everything worth keeping is in /app/data. Mount it on persistent storage and back it up (see Running dpndncY).
4. Two addresses must be set. The backend refuses to start in production without CORS_ORIGIN, and it needs APP_SECRET. The Compose file and the Helm chart derive the address variables from one setting (DOMAIN or config.publicUrl), so you rarely set them by hand.

#Requirements

Scans are CPU and memory heavy, and a large repository can take minutes. The container is limited to 2 CPUs and 4 GB in the Compose file; raise that for heavy use. The System health page shows event-loop lag, which is the first sign a machine is too small.

#Images

ghcr.io/dpndncy-sca/platform is published on every release:

#Setting up a new workplace

For a company that gets its own installation, the sequence is the same on every platform:

1. Deploy with one of the guides above, with ENABLE_BOOTSTRAP_SUPERADMIN=true and a SUPERADMIN_EMAIL and SUPERADMIN_PASSWORD of your choosing. This creates the first operator account.
2. Sign in at the console address and change nothing else yet. Then set ENABLE_BOOTSTRAP_SUPERADMIN=false and restart. While it is true, every restart resets the operator password to the configured one.
3. Create the workplace's tenant (Settings, Customers, or POST /api/admin/tenants) with the company's first owner. See Tenants, users and access. A tenant is the unit that owns projects, scans, users and a scan policy.
4. The owner signs in, enables two-step verification, optionally turns on enforcement for everyone (Settings, Sign-in security), and invites colleagues.
5. Pick the scan policy (Settings, Scan policy). See Scan policies.
6. Connect pipelines. The owner creates an API token (Settings, API Tokens) and gives it to CI as a secret. See Scanning from CI/CD pipelines and The dpndncy command line.
7. Activate the licence (Settings, License). A new installation runs a 30-day trial; after that it becomes read-only (existing data stays readable, new scans are blocked) until a licence is applied. A licence can be activated online, from an activation code, or imported from a file for air-gapped sites.

A company that shares an installation with others (a service provider hosting several customers) uses the same installation and creates one tenant per customer in step 3. Customers never see each other's data.

#Checking a deployment

#Not covered here

The Windows installer (dpndncY-Setup-<version>-x64.exe, built from installer/) installs the platform on a Windows machine under PM2. It is intended for evaluation and small sites; use the container for anything that has to run unattended. The Packer files in deploy/packer build a virtual machine image that runs the installer on first boot.