dpndncY

Handing dpndncY to a customer

A checklist for the person delivering dpndncY to a customer: what to ask for beforehand, what to hand over, how to prove it works, and what the customer does after you leave.

#1. Before you start: what you need from the customer

Send this list a week ahead. Most delays come from DNS, certificates and the network.

Ask for Why
Where it will run: a Linux machine, a Docker host or a Kubernetes cluster Chooses the guide (Deploying on one Linux machine, Deploying with Docker, Deploying on Kubernetes)
Two DNS names, for example dpndncy.<theirs> and api.dpndncy.<theirs>, pointing at it One for people, one for pipelines. See Ports and networking
Certificates: public (Let's Encrypt) or from their own authority Decides the proxy configuration
Firewall and proxy: TCP 443 inbound, outbound HTTPS to the listed destinations, or a proxy The network team needs the note in Ports and networking
Machine size: 4 vCPU, 8 GB memory, 50 GB disk for a team (minimum 2, 4, 20) See Deploying dpndncY
How they sign in: local accounts, or OpenID Connect or SAML Identity provider details, redirect addresses
An SMTP relay (optional) Invitations and alerts. Without it, set initial passwords by hand
Which CI systems and which languages To prepare the pipeline examples (Scanning from CI/CD pipelines)
Whether the machine has internet access If not, plan the offline route (Getting the software, Running dpndncY without internet access (air-gapped))
A named owner on their side and an administrator Who becomes the first tenant owner

#2. What you hand over

Item Notes
The software The image, deployment files and chart, by one of the routes in Getting the software, with checksums
A licence A key or activation code, applied in Settings, License. A new installation runs a 30-day trial, then becomes read-only until a licence is applied
Access to the documentation The documentation website, and the files for offline sites
A support route An email address and what to include: version, a description, the relevant log lines
The operator credentials, by a secure route Generated on the machine at install. Never email a password. The operator password is only needed to create tenants

#3. The installation visit

  1. Check the prerequisites above are real: the names resolve, the ports are open, the machine has the right size.
  2. Install (Deploying on one Linux machine is a single command).
  3. Sign in as the operator. Then set ENABLE_BOOTSTRAP_SUPERADMIN=false and restart, so a restart cannot reset the password.
  4. Create the customer's tenant and its first owner (Tenants, users and access).
  5. Apply the licence.
  6. Ask the owner to sign in, set up two-step verification, and turn on enforcement for everyone.
  7. Choose the scan policy together (Scan policies). Start permissive and tighten. Going straight to a strict profile fails almost every project on day one and teaches people to ignore the result.

#4. Acceptance: prove it works end to end

Run these with the customer watching. All should pass.

Check Expected
curl https://<api>/health from a laptop and from a CI runner {"status":"ok","version":"..."}
Sign in to the console in a browser, through the real names The dashboard
Create a pipeline token (a service user with the analyst role) and run dpndncy status --server https://<api> --token <token> from a runner Server reachable
Scan a real repository from their CI with dpndncy scan --ci --project <name> . A result, and an exit code that matches the policy
Change the policy in the console and run the pipeline again The result changes with no pipeline change
Restart the stack (docker compose restart or delete the pod) Data is still there and the API token still works
Take a backup and note where it goes (Running dpndncY) A backup file off the machine

#5. Teach the customer these five things

  1. Two addresses, two jobs. People use the console name, pipelines use the API name. If a pipeline gets a 404, it is using the wrong one.
  2. The scan policy decides pass or fail. It is chosen in the console, so changing it needs no pipeline change.
  3. One container, one volume. Back up the volume. Do not run two copies.
  4. Rotation. The signing key rotates itself. They should set API_TOKEN_MAX_DAYS and rotate the pipeline tokens on that schedule. APP_SECRET changes only with the tool (Running dpndncY).
  5. Upgrades are deliberate. Pin the version, back up, upgrade, check /health.

#6. After you leave

The customer should By
Have a backup running and a restore tested Week 1
Have all pipelines scanning, each with --project set Week 2
Review the scan policy and move it one step stricter Month 1
Rotate the pipeline tokens Every 90 to 365 days
Update the platform Every release, after reading the changelog

#What dpndncY does not do

Be clear about these so expectations are right:

  • It is one container per installation. It scales up, not out. Size the machine for the busiest day.
  • It has no external database option. The database is SQLite, in the data volume.
  • A scan finds known vulnerabilities and risky code patterns. An attack path is a ranked lead, not proof that something is exploitable.
  • Framework-named policies follow the intent of a framework. They help meet a standard but are not a certification.
← Previous
Air-gapped sites
Next →
Configuration