From nothing to a first scan, in about ten minutes

1. A machine with Docker

   Any Linux host with git, docker and the compose plugin, and a user that can talk to the docker daemon. That is the whole list of prerequisites. Four cores and eight gigabytes of memory comfortably covers a few hundred repositories on a nightly schedule.

2. One command

   It clones the project, asks six questions that all have sensible defaults, builds the image, starts it, waits for the health check to pass and prints the username and password to sign in with. Running it a second time reads your existing settings and offers them back, so you can change one answer without retyping the rest.

3. Sign in and lock the account down

   The first administrator password is generated on first boot, written to one file inside the database volume with mode 600, and printed once. You are made to change it and set up a second factor before you can reach anything else. Save the recovery codes somewhere other than the laptop you just set them up on.

4. Add a connection

   A host, a read only credential and a scope. Start with one organization rather than the whole estate: the first scan tells you more about how long your estate takes to read than any estimate will.

5. Scan

   Press the button. Watch the log. The first run of a large organization takes a while because it is cloning every branch and full history of everything in scope, and later runs on the same machine reuse a great deal of that work.

6. Then tune it, once, properly

   The first list is longer than the real one. Set a baseline if the backlog is historic, look at the top ten rules by count and decide whether each of them is telling you something, and use the recommended grades. An hour spent here is the difference between a list people work through and a list people close.

Read only, always. The product never writes to a repository and refuses to ask for permission it does not use. On GitHub a classic personal access token with repo and read:org is enough to start; add security_events if you want the host's own Dependabot and code scanning alerts folded in.

It listens on loopback by default and speaks plain HTTP, on the assumption that something in front of it is terminating TLS. That is one nginx or Apache block. Do not put it on a public address without one.

Nightly per organization is the usual answer, staggered so the whole estate is not cloned at once. Notifications on what is new rather than on the standing backlog is the other half: a daily message about findings nobody has acted on teaches people to filter the sender.