Release notes

v0.2.0

A minor release. Upgrade from v0.1.0 or v0.1.1 following Upgrade. It carries 18 schema migrations, which run as a pre-upgrade hook, so take a backup first. Every one only adds, so rolling the platform back to v0.1.x afterwards is safe; see Roll back.

Fleet bans start being enforced

On v0.1.x the fleet-ban artifact was written in a format agents could not read, so every agent loaded zero fleet bans while the publishing job reported success. From v0.2.0 they load. Agents with platform.fleet_bans.enforce on will start refusing traffic they did not refuse before. Review your fleet bans, or turn enforcement off, before you upgrade.

Invitation links issued on v0.1.x stop working

Invitations are now tracked in the database, and links issued before the upgrade are not in it. Re-invite anyone who has not accepted yet.

Check externalScheme in your values before upgrading

externalScheme was ignored on v0.1.x and is read from v0.2.0. If your values carry a top-level externalScheme that has never had any effect, it takes effect on upgrade and changes the scheme in the dashboard's sign-in URL. A scheme that does not match the address people actually type is rejected as Invalid origin.

helm get values g0s -n gen0sec | grep externalScheme

Remove it or correct it before upgrading. Nothing to do if you pass examples/single-entrypoint/ingress-values.yaml unchanged: it ships externalScheme: https, which is the scheme v0.1.x effectively used anyway.

Added

• Passkeys. Users can register and sign in with a passkey, and manage them under Profile. Passkeys are bound to the published host name and need HTTPS. See Sign-in and identity.
• Invitation and password-reset email, through your SMTP server. Without SMTP, invitations fall back to a link you copy. See Invitations and email.
• Role-scoped invitations. An invitation grants specific workspaces, each with a role no higher than the inviter's. Pending invitations are listed and can be revoked, and access to one workspace can be revoked without removing the person.
• Audit log, under Organization settings for the Owner and Admin roles. It records changes made in the dashboard and rule changes made through the signal API, with source IP and user agent. It is kept indefinitely; see Known limitations.
• Components, under Organization settings: what each component runs, against the latest version known to the release. An online check for newer versions is off by default. See Component versions.
• WAF rules accept regex_replace() and the http.request.raw_path field. See Known limitations for agent versions.
• CACHE_L1_TTL sets the default lifetime of the in-process cache, as a duration. Default 30s, up from a fixed 15s. Set it through global.commonEnv.

Fixed

Fleet bans never reached agents. See the warning above.

Block events were lost in several ways. Each of these applied to v0.1.x:

• A batch of more than 20,000 records was refused whole, and OTLP senders do not retry that. The first 20,000 are now kept.
• One row the database refused sent its whole insert batch, other organizations' rows included, to the dead-letter topic. Only the refused row is parked now, with the reason in a dlq_reason header.
• A NUL byte in any field, a source_ip that was not an IP address, or a non-ASCII country code made the database refuse the row. These are now cleaned or dropped, and the event is kept.
• A non-integer hit count stalled the dashboards' aggregates for every organization. It is now dropped, and the event kept.
• An agent newer than the platform could report a source the platform did not know, and the event was refused. It is now stored without its source. fleet_ban is also accepted as a source.
• IDS alerts were rejected as malformed block events and warned about once a minute. Records that are not block events are now skipped quietly.

Block events lacked country and ASN whenever the GeoIP lookup missed, although the agent had sent them. The country is also stored in upper case, so us and US no longer count twice.

Drops made by the agent's kernel IP filter were not stored. The agent reports them as dropped_ip records rather than block events, and those were skipped, so for an agent enforcing in the IP filter the access-rules views stayed empty. A drop the access rules caused is now stored as an access-rules block event, with its count as the hits and bpf:ip_filter as the rule.

Writing a managed WAF rule failed with column s.rule_managed_id does not exist.

--set entrypointHost had no effect. Following the Publish the endpoints procedure verbatim published every route on the placeholder gen0sec.internal whatever address you passed. The overlay carried the host as a YAML anchor, and anchors are expanded when the file is parsed, before Helm merges --set, so the flag rewrote the top-level key while all ten rules kept the value the file shipped with. No template read the value either, so removing the anchor alone would not have helped.

The failure was silent. The Ingress objects were created and looked correct, but Synapse keys its upstreams by host and serves nothing for an address no rule names. The chart now resolves the entrypoint itself and publishes every rule under it.

The dashboard's sign-in URL could be absent. BETTER_AUTH_URL was derived from the first entry of a service's ingress.hosts. With the address named once in entrypointHost that list is empty, so the variable was not wrong but missing, and Better Auth rejected every sign-in with Invalid origin. It now follows the same entrypoint the rules do.

Changed

An empty entrypointHost now fails the render instead of publishing host-less rules. Such a rule matches every Host header and Synapse's operator skips it, so it could only ever be a misconfiguration that reported nothing. helm upgrade now stops and names the value to set.

Rules that carry their own ingress.hosts[].host are unaffected and still need no entrypointHost.

entrypointHost is required from the first install, before anything is published. The dashboard's sign-in URL now always comes from, in order: services.ui.env.BETTER_AUTH_URL, the dashboard's own ingress.hosts[0].host, then entrypointHost, whether or not its Ingress is enabled. With none of them the render fails and names entrypointHost. It was previously derived only once the dashboard's Ingress was enabled. Install and Upgrade pass it.

--set externalScheme had no effect either. Same defect, same shape: nothing read the top-level value, and the single-entrypoint overlay pinned the dashboard's own scheme on top of it, so the flag was inert twice over. It only ever looked correct because what it pinned was https, which is what a right answer produces anyway. The wrong scheme in the dashboard's base URL is rejected as Invalid origin, so this mattered to anyone terminating TLS upstream who needed anything else.

The chart reads the top-level value now, and the overlay stops pinning the dashboard. services.<service>.ingress.externalScheme still overrides it for one service.

A value that was inert becomes live. See the warning at the top before you upgrade.

The dashboard holds one namespaced permission. The infra chart adds the Role and RoleBinding g0s-ui-read-installed-versions in gen0sec-system, allowing get on two named ConfigMaps, and the dashboard's service account token is now mounted. Nothing to do on the documented release names. Otherwise set components.ui.*; see Upgrade and Privileges and RBAC.

The dashboard makes optional outbound calls, none carrying agent data. See Ports and egress.

telemetry-api logs what it drops, once a minute per organization, and its existing decode warnings are rate-limited the same way. See Monitor.

Rule changes made through the signal API are audited in the same transaction. If the audit record cannot be written, the rule change is not applied. See Symptoms.

The Agents item is hidden from the dashboard navigation on self-hosted installs.

One migration waits at most 10 seconds for a lock on the block events table. On a busy install it can fail and is safe to retry. See the note in Upgrade.

Security

• gRPC 1.83.2, fixing an HTTP/2 memory exhaustion reachable in the APIs (GO-2026-6348), and OpenTelemetry 1.47.0. Other Go modules updated for advisories that were not reachable.
• Next.js 16.3.7 and React 19.3.0, fixing CVE-2026-94545 as first shipped in v0.1.1.
• better-auth 1.7.7, and the dashboard's dependency overrides enforced so pnpm audit is clean.

Documentation

• These docs are now versioned, with a version selector. v0.1.0 and v0.1.1 each keep their own version, with both defects above listed in their known limitations.
• Publish the endpoints documents --set externalScheme=https again, now that it works.
• Upgrade now passes the ingress overlay to the platform upgrade. Without it, the upgrade removes every Ingress.
• Roll back uses the db-migrate image of the release you are leaving. The previous image cannot run the down migrations.

v0.1.1

A security patch for the dashboard. It fixes CVE-2026-94545 (medium, CVSS 4.0 score 5.3), in which Satori, the HTML-to-SVG library Next.js bundles for next/og, did not escape certain values in the SVG it generates. The dashboard does not render images through next/og, but the vulnerable copy shipped in its image and scanners flag it.

The fix updates Next.js from 15.5.24 to 16.3.7, and React from 19.2.3 to 19.3.0. It upgrades in place from v0.1.0, with no migration and no values changes.

Nothing else changed: the procedure is v0.1.0's, and its known limitations still apply.

v0.1.0

First on-premises release.

Installing

Two methods, both documented on one procedure that branches once: install from our registry, or create an offline bundle and mirror it into your own.

Requires

Kubernetes	1.23 or later
Nodes	3 for production, 16 vCPU and 32 GiB each recommended
Storage	sized to your retention
Cluster egress	api.gen0sec.com:443, required

Credentials you need

Two, and the second is easy to miss. Both are self-service from the dashboard:

1. A registry token, for pulling charts and images. Created under Repository Access. The install kit itself is public and needs no credentials.
2. Your Gen0Sec API key, which the relay uses to fetch data from us. Without it the whole fleet receives empty artifacts with no error. See Credentials from gen0sec.

Not in this release

Zero-egress deployment	Known limitations
Explicit egress proxy for the relay	Known limitations
Single sign-on of any kind	Email and password only. Microsoft Entra ID is in development
Shipped dashboards and alert rules	Monitor lists what to watch meanwhile
The threat service	Not shipped at this release

---

How we version

Scheme	Semantic versioning. Each minor is a release train
Supported	The latest two minor trains
Upgrades	Sequential minors, patches in place. Skipping a minor is not supported
Release candidates	Not published to releases.gen0sec.com. Only stable releases are mirrored

Full policy: Component versions.

Finding a release

curl -fsSL https://releases.gen0sec.com/api/repos/cerebellum/latest | jq -r .tag_name

Returns the latest full release. Pin the tag explicitly for an install you want to reproduce, so a rebuild in six months fetches the same bytes.

What every release publishes

Artifact	Where
Install kit and its signature	https://releases.gen0sec.com/cerebellum/<tag>/
Images and charts	The registry, each pinned to a digest in the kit's release manifest
Signatures and SBOM attestations	Alongside each image and chart, as OCI referrers

See Supply chain.