The private registry

Every Nyxus image and the Helm chart live in a private registry at
registry.nyxus.co.uk. Your licence key is the credential for it. There is no
separate registry username to manage, no service account to create, and no
token to rotate on its own schedule - the key you were issued is the key that
pulls.

Signing in

read -rs NYXUS_KEY    # paste the key: not echoed, not kept in your history
docker login registry.nyxus.co.uk --username licence --password-stdin <<<

The username is the literal word licence. The password is the key.

Reading the key into a variable rather than typing it on the command line
keeps it out of your shell history, and --password-stdin keeps it out of the
process list. Both matter more than they look: a key in ~/.bash_history on a
shared build box is a key anyone on that box can pull with.

Pulling the chart

The chart is an OCI artifact in the same registry, so Helm uses the same login:

helm upgrade --install nyxus \
  oci://registry.nyxus.co.uk/nyxus-enterprise/charts/nyxus \
  --namespace nyxus --create-namespace --version <version

helm show readme oci://registry.nyxus.co.uk/nyxus-enterprise/charts/nyxus
prints the chart's own README, which documents every value.

Pulling nyxusctl

The command that installs and upgrades a deployment is published to the same registry, per release, behind the same key. It is a plain HTTPS download rather than an OCI pull, so curl is all it takes:

curl -fL -u licence:"$NYXUS_KEY" \
  https://registry.nyxus.co.uk/cli/0.6.0 -o nyxusctl.whl
pipx install --force ./nyxusctl.whl

Ask for a released version, not latest. A running portal also serves the wheel for the release it is running, under System health > Updates, which is the right answer for an install and the wrong one for an upgrade - it hands you the command of the release you are leaving. Use the registry when you want a particular version, or when there is no portal yet.

In a cluster

The chart creates the image pull secret from the key you give it, so you do
not have to make one by hand. You can bring your own instead if your cluster
already has a pattern for that - the chart's README covers both.

Whichever way, the secret is what every pod uses to pull. A node that cannot
reach the registry gives you pods stuck in ImagePullBackOff, which is the
same symptom as a wrong key and is worth telling apart before you go looking
for the key.

Checking a signature

Every image and the chart are signed. Verify before you deploy:

cosign verify --key nyxus-images.pub --insecure-ignore-tlog=true \
  registry.nyxus.co.uk/nyxus-enterprise/receiver:<

The public key is printed in the chart's README, so a verification does not
depend on fetching a key from the same place as the artifact it checks.

--insecure-ignore-tlog is there because the signatures are not in a public
transparency log. That is deliberate for a private registry: publishing the
log would publish who is running which version, and when.

The current key signs 0.2.0 and later. 0.1.0 was signed with an earlier key,
published alongside it so those images stay checkable.

When a pull is refused

An authorisation error on the first pull is the expected answer to an
unlicensed install, not a fault to diagnose. Work through it in this order:

1. Is the key the whole key? They are long, and a copy that stopped at a
   line break fails in exactly this way.

2. Is the username licence? Not your email, not your company name.

3. Has the term ended? The portal shows the subscription state under
   Administration > System health. An expired key is refused at the registry.

4. Has the key been revoked? A key can be withdrawn - after a leak, or
   when a deployment is replaced. The refusal looks identical to an expired
   one at the registry, and the portal tells them apart.

5. Can the machine reach registry.nyxus.co.uk at all? A proxy that
   intercepts TLS will fail here before any of the above matters.

Why the subscription check exists

The receiver confirms the subscription with the registry every few hours. It
sends what it must and nothing else, and the security guidance sets out
exactly what that is.

If the check cannot be made - a firewall rule, an outage, a lapsed term - the
deployment keeps working for fourteen days, then stops accepting new
findings and new enrolments. What is already recorded stays readable. The
portal says so from the first day, so the grace period is a warning you can
act on rather than a surprise.