StackRox has been renamed three times and its Makefile still says apollo

The build system still calls the project apollo

The page states the lineage in one sentence: the platform is built on the foundation of the product formerly known as Prevent, which itself was called Mitigate and Apollo, and it warns that you may find references to those previous names in code or documentation. Two of the references are not in documentation. The Makefile sets a variable called ROX_PROJECT to apollo, which is the first name in that chain, and the Go module path is github.com/stackrox/rox rather than the repository's own name. Those are the two files a build touches before anything else, so the identifier a compiler sees is the oldest name the product ever carried, four names back. Nothing breaks because of it, and it does mean that searching the project's issues for a stack trace often turns up a string with no obvious connection to the platform you installed. It also means a rename, when it comes, will not be a single edit.

The recommended install path sits above the deprecation warning

The deployment section opens with a single line saying that as of release 4.10 it is possible to install StackRox using the operator, and the next thing on the page is a warning block stating that the following installation methods are deprecated. Everything after that line, the Helm quick install, the manual Helm walkthrough and the script-based path with its distribution-specific branches, all sit under the warning. The table of contents at the top of the page tells a different story: Quick Installation using Helm first, Manual Installation using Helm second, Installation using the Operator third. So the contents promise a Helm-first document and the body delivers an operator-first document with Helm underneath a deprecation notice. A reader arriving from a search result on the anchor for the quick install lands in material the same page has marked as on its way out.

The quick install is a curl piped into bash, from the master branch

The shortest path installs your security platform like this:

/bin/bash <(curl -fsSL https://raw.githubusercontent.com/stackrox/stackrox/master/scripts/quick-helm-install.sh)

The URL points at the master branch of the repository rather than at a release tag, so what runs is whatever that branch holds at the moment you execute it. The page says the script adds the Helm repository, generates an admin password, installs central services, creates an init bundle for provisioning, and finally installs the secured cluster services on the same cluster. It also says the script will open a browser and log you in, and that a certificate warning may be displayed because the certificate is self-signed, with the dashboard reached over HTTPS on port 8000 of localhost. A separate flag exists for clusters too small for the default CPU and memory requests, and the page says plainly that it is not recommended for production.

The admin password is generated by openssl, then typed on a command line

The manual path makes you create the admin password yourself:

ROX_ADMIN_PASSWORD="$(openssl rand -base64 20 | tr -d '/=+')"

Twenty random bytes, base64 encoded, with the slash, equals and plus characters stripped out, which is what makes the result safe to hand to Helm as an argument. The generated value is then passed into the upgrade and install command as a set value for central.adminPassword, which means the secret lands in your shell history before it reaches the release. The same command sets central.persistence.none to true, so Central keeps nothing on disk by default, and the page notes separately that you need only one deployed instance of central services no matter how many clusters you go on to secure. That is the right shape for a centralised control plane, and it is also the shape where losing the cluster loses every managed cluster's configuration with it.

The Helm repository is a raw GitHub URL

The repository you add is not a chart registry:

helm repo add stackrox https://raw.githubusercontent.com/stackrox/helm-charts/main/opensource/

A repository index served straight out of the main branch of a different repository. Listing what is on offer is a helm search repo against that index, and the page notes that adding the devel option shows non-release builds as well. So the charts track the tip of main in a sibling repository, which is a sensible way for a project to ship its own charts and a perfectly reasonable default for a first install. It also means two version numbers live in two different repositories and are not obviously related to each other. A deployment that pins an image tag but installs a chart from a moving branch has pinned one half of the system, and the page does not describe a version pairing that would close that gap.

Three database packages are excluded from unit tests, with a ticket

The Makefile carries a variable named for the ignore list, taking pipe-separated file patterns and passing them to grep as an exclusion. It names the sensor tests, the operator tests, the scanner end-to-end tests and three Postgres store packages, covering configuration scan reports, compliance operator scan configurations and authentication. Sitting directly above it is a comment marking a TODO against an internal reference and asking for Postgres store test generation to be updated to work for foreign keys. So the exclusion is not unexplained: three layers of the central database have no generated unit tests because the generator does not handle foreign keys yet, and the work is tracked. That is better disclosure than most repositories manage, and it is also a map of the platform, telling you which parts of the control plane have no fast test standing behind them. The same line hard-codes unit test flags to the race detector with a parallelism of four.

Benchmarks are pinned to a single iteration

Benchmark behaviour is set by three variables in the same file, with defaults declared so a developer can override them: the benchmark time is 1x, the timeout is twenty minutes and the count is one. In Go, one iteration means every benchmark case runs exactly once and reports that single run. Unit tests get the opposite treatment, since their flags are set unconditionally to the race detector with a parallelism of four. So the committed defaults give you concurrency checking on correctness and no averaging at all on speed, which is the setting that produces the noisiest number a Go benchmark can produce. The override is one variable away, and anyone running a real comparison raises it first. What is worth noticing is that the default in the repository is the one that would mislead someone who ran a benchmark, saw a result and believed it.

Docker and Podman get different security options

The build defaults its container engine to docker and then spends three separate attempts deciding whether podman is really what is installed: one on an explicit engine setting, and two that run the docker version command and grep its output for the word, because a docker binary may be a podman shim. A fourth check swaps in podman outright when docker is not on the path at all. Once the engine is known, the two branches differ in what they do to the container. Podman builds run with SELinux label enforcement disabled, for local builds. Vanilla docker builds instead run the container as the invoking user id, and a comment next to it explains that podman already runs processes unprivileged but its user id mapping is more nuanced. Four probes, two security models and one comment carrying the reasoning is a fair summary of the state of container tooling in 2026, and it is all in the first forty lines of the build file.

Editorial conclusion

This is a serious piece of infrastructure with unusually honest build files, and both halves of that are worth using. The deployment guide is specific about cluster sizes, about the self-signed certificate you will see, and about which of its own paths are deprecated. The Makefile names the tests it excludes and the ticket that explains why. What you should weigh before committing is the shape of the install: a script fetched from a branch tip, a password generated into a shell variable and passed as a Helm argument, a chart repository served out of another repository's main branch, and a self-signed certificate, all of which are reasonable for evaluating the platform and none of which you would hand to a production cluster unchanged. Pin the chart and the image by version before you go further, replace the generated password with one your secret store issues, and budget for the operational surface, since the repository carries several hundred open issues.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes