What Nyxus needs to run
Install and run
Resources, ports, the log store, and how it grows with the estate.
Nyxus is deliberately small. Two containers hold the whole product, and
neither keeps anything you could not rebuild. Almost everything below is about
what they talk to rather than what they consume.
The two services
What it does | Listens on | |
|---|---|---|
Receiver | Accepts findings from collectors, scanners and the extension, and writes them to your log store. Holds device enrolments, accounts, decisions and teams. | 8080 |
Portal | Reads findings back and derives everything you see. Holds no findings of its own. | 8091 |
The chart asks for 50m CPU and 96Mi of memory each, with a 256Mi limit,
and that is not an under-estimate to make the numbers look good - the receiver
writes JSON lines and the portal does arithmetic. If a page is slow, the log
store is almost always where the time goes, not these two.
Both run as uid 65532, as a non-root user, with no Kubernetes API access and
no service account token mounted.
The receiver keeps state on a volume: 1Gi by default,
holding the accounts, device enrolments, tokens, decisions, teams and the
recorded daily history. The findings themselves are not in there.
Two optional jobs run beside them: the scanner, which reads your cloud and
fleet sources, and discovery, which finds AI domains the registry has
never heard of. Each runs, sleeps and runs again - a day and a week by default.
A log store
This is the one real dependency, and Nyxus does not ship you one. It writes to
Loki, or to anything that speaks the same push and query API, and it points at
whatever you already run - because most people deploying this have a log store
already, and adding a second one is not a favour.
Volume is the thing to plan for, and it is a function of your estate rather
than of Nyxus. A finding is a single JSON line. Personal-account findings
report at most hourly per machine and everything else at most daily, which is
deliberately throttled at the collector so that scheduling a policy often does
not flood your store.
If you have no log store at all, both the chart and the Compose file can start
Loki and Grafana for you. That is fine to evaluate with. It is not where you
want a year of evidence to live.
Outbound access
To | From | Why |
|---|---|---|
| Receiver, portal, and whatever pulls images | Images, the chart, and the subscription check |
Your log store | Receiver (write), portal (read) | Findings in and out |
Microsoft Graph | Scanner | Entra sign-ins, consent grants, service principals, Exchange evidence |
Your MDM | Scanner | Jamf or Intune inventory |
Your EDR or DNS product | Scanner | SentinelOne and equivalents |
Your receiver | Every collector, and every browser with the extension | Reporting |
The first one is the one people miss. If the registry is blocked, the
deployment keeps working for fourteen days and then stops accepting new
findings and new enrolments. The portal says so from the first day, but a
firewall rule missed at install is a fortnight's delay before anybody notices.
Put it on the allowlist at the same time as Entra and your MDM.
Inbound access
Only the receiver needs to be reachable by the fleet, and only for reporting.
The portal is for people, and where you put it is your decision.
Neither container terminates TLS. Both bind to loopback in Compose, and the
chart leaves the ingress to you, because "reachable" is a decision made with a
reverse proxy in front rather than one a deployment file makes on your behalf.
What runs on the machines
A collector is a single script, run as root on whatever schedule you already
use. No agent, no service, nothing listening. It runs, reports and exits. See
Installing the collectors.
The browser extension is packed and deployed by you through browser policy,
not installed from a web store. See
The browser extension.
Kubernetes, or not
Kubernetes is not a requirement. If you already run it, the chart is the
better route and installs from the registry with
Helm. If you do not, Docker Compose deploys the same
two images on one host.
The only thing you give up on Compose is what Kubernetes itself would have
given you: scheduling, restart policy, and somewhere for the volume to come
from.