Stardust

An identity provider you run yourself — and can see all the way through.

Stardust decides who a person is, how they prove it, and what your applications are told about them. It runs on your servers, it has no screens of its own — the API is the product — and nothing in it reports to anybody.

The problem

What makes an identity provider dangerous is rarely what it lacks. It is what it does without anyone knowing: a capability switched on that nobody switched on, a door kept for its own console, a feature you did not know you had.

Stardust was written after measuring exactly that on the identity provider we used before. It has fewer features than the established products, by choice, and every one of them follows from two rules.

Two rules

Nothing is active unless somebody declared it.
The panel, the MCP server, impersonation, remembered browsers, per-person consent, notifications: all off until an operator switches them on. A setting whose default would widen what somebody can do defaults to the narrow value.
Nothing happens that you cannot see.
Every act that changes something is in the audit log, with who did it, through which application and why it was allowed — refusals too. An administrative act whose record cannot be written does not happen.

What it insists on

No sign-in without the person
No operation produces a session without one of the person's own factors. It is not a check that could be misconfigured: the operation does not exist.
The API is the product
Your applications, the command-line tool and the optional panel use the same public API, with the same powers. There is no private door reserved for a console.
An application learns an identifier, and nothing else
Each application gets its own identifier for each person, so connecting two applications is a decision, not an accident. Everything else is released per application, and an organization can only take away.
A licence never stops a sign-in
When a licence ends, administration stops — people keep signing in, and taking access away never stops. No way of proving who you are is ever under licence.

What it does

Signing in

OpenID Connect, done strictly
Authorization code with PKCE required by default, return addresses matched exactly — never by prefix — and codes that live 60 seconds. Live discovery and JWKS; tokens signed with a key created on your machine that nobody else ever sees.
Passkeys and second factors
Passkeys bound to your issuer, so they cannot be phished; authenticator apps; ten single-use recovery codes. When instance and organization policies differ, the strictest wins, and the amr claim tells applications which factors were used.
Passwords that hold
Twelve characters by default, checked against some 100,000 known breached passwords — a list you can replace with your own — and a brake on repeated attempts and on sources spraying many addresses.
Single sign-on, without a hidden session
One sign-in screen mints codes for your other applications. There is no server-side login cookie for anyone to steal, and a restart logs nobody out.
A recent proof for acts that last
Granting powers, setting a password, adding a factor: anything that outlives the current sign-in asks for a fresh proof of identity. Credentials expire when idle and at a hard ceiling, and a revocation applies on the very next request.

Identity and data

Organizations, and never a “tenant”
People belong to the instance and to any number of organizations. In organization mode a sign-in is the pair person-in-organization, and never reveals anything about anywhere else. Invitations need the person's consent.
An identifier per application
A pairwise subject for each application — and for each organization, in organization mode. Applications see the same person only by declaring a correlation group, and attributes that could link them are flagged and listed.
Attributes released on purpose
By default an application receives nothing beyond the identifier. Release is declared per application, organizations can withhold, and optional per-person consent lets a person refuse. Token, API and notifications give the same answer, from the same rule.
Powers, not administrators
Nobody is an administrator: authority is a grant of a power, with a reach, an optional end date and the name of who gave it. Roles such as help desk, compliance or incident response expand into separate grants, and you can only grant what you hold.
Impersonation that shows
Nobody holds it by default and no role contains it: it is granted on the host only, for one application at a time. The token carries the act claim, every use is audited, and it never touches the person's password or factors.

Seeing it, and running it

An audit log that does not lie
Every act and every refusal, with the names as they were at the time. If an administrative event cannot be written the act is refused; sign-in never stops — its events wait in a local spool until the database takes them.
Signed notifications
Sign-outs, deactivations, group and organization changes reach your applications as signed security events — only for people they already know, only to origins you allow, retried for up to seven days.
A contract generated from the code
The OpenAPI description is generated, never written by hand: every route, every error code it can return, the power it needs. Breaking changes are declared by kind, and a release that breaks the contract without saying so does not ship.
Signed releases, signed updates
Every image and the update feed are signed, and an image that does not verify is not ours. stardust upgrade works out the chain of steps; each costs about a second and a half of sign-in. Security advisories travel in the same signed feed.
stardust doctor
Eight checks, no sign-in needed, an exit code your alerting can use — and output that contains no passwords, no personal data and no secrets, so it can be sent to whoever helps you.
Agents, read-only
An MCP server, off by default. Its developer tier serves the contract and the concepts, never a person's data; the admin tier, switched on separately with short-lived personal tokens, reads and suggests — it never acts.
An optional panel
A web interface for the instance, off by default and absent when off. It uses the same public API and the same powers as everything else, and leaves the recovery doors on the host where they belong.

What an operator reads

No screenshots: Stardust has no screens of its own. This is the real output of stardust doctor in 2026.10.1 — the format as it ships; the names, address and dates are an example.

$ stardust doctor
ok     the instance                answers on http://localhost:8080
ok     this artifact               release 2026.10.1, released 2026-10-01 — signed, kid artifacts-2026.9-0fa2b10a
ok     the schema version          recorded: 2026.10.1
ok     the signing key's secret    read, and nobody else on this machine can reach it
ok     the audit spool             empty: everything has reached the database
ok     the breached-password list  97746 entries from /srv/apps/api/data/breached-passwords.txt.gz
ok     what verifiers are served   issuer https://id.example.com, key set advertised at https://id.example.com/.well-known/jwks.json, 1 key(s) served: Qm8sXn2LwT4yVb7cPz1eRA
ok     the licence                 Example S.p.A., production, until 2027-09-30; 3 organization(s), no limit; remembered

Nothing here needs you.

What it does not do, on purpose

It does not call home
No telemetry, no licence check over the network, no report of what is installed. The update feed is read only when asked, and sends nothing about your instance.
It does not own your login screen
It hosts no sign-in page and sends no email: an email with our words and our brand is a message your customer never wrote. Stardust provides the mechanism; the words are yours.
It does not reach into the host
It has no access to the container runtime. An upgrade is a command it prepares and explains, and that you run.
It does not depend on other services
Postgres is its only dependency: no message queue, no cache server, nothing managed by anybody else.
It is not operated by us
Its makers cannot see into it and have no access to it. When you need help, the doctor's output is what you send.

Who it is for

Companies that must keep identity on their own servers — regulated work, closed networks, or simply a policy.
Software houses whose applications serve many customers that must never learn about each other.
Teams that want to know, before they trust an identity provider, what it does with every setting and why.

How it runs

Delivered as: One OCI image for linux/amd64 and linux/arm64, with the command-line tool inside, and an installation kit for Docker Compose.
Needs: Docker with Compose v2 and Postgres — the kit brings one, or use yours. Nothing else.
In front: Your TLS reverse proxy, such as Caddy or nginx. Stardust listens on 127.0.0.1 only, and the database publishes no port.
Outbound: Optional: the signed update feed, and the notification origins you allow — none by default. Both can be closed.
Closed networks: Per-architecture archives for docker load, and the manual shipped inside the image, readable offline.
Backups: Database, audit spool and secrets, with the secrets kept apart — a script and a timer come with the kit.

What it costs

A subscription. The licence is a small file we sign, checked offline: it says who it is for, until when, and how many organizations it opens. People and applications are not counted.

It covers the versions released while it is active. When it ends, administration stops and sign-in does not. Second factors, passkeys and recovery codes work with every licence — charging for them would pay people to stay on the weakest method they have.

An evaluation licence is issued on request: thirty days, three organizations, not for production.

Run your own identity provider, and see everything it does.

Ask for an evaluation licence Talk to us