Security & Trust
NYXDB is self-hosted: it runs inside your own environment, so your existing network, encryption and access controls apply directly and nothing flows through a cloud we operate. Below, what the engine itself does to protect you, and how to report a vulnerability.
Posture
Four properties you get before any control your own environment adds around it.
Credentials never touch your query text: passwords arrive as bound parameters and are stored only as Argon2id hashes. API key secrets are shown once, at creation, and query history records credential statements only in redacted form.
Access ends the moment you revoke it: passwords and API keys mint short-lived signed bearers that are exchanged for a session, and disabling a user or key revokes its bearers. Another instance reads only what an application access grant allows, row predicate included.
You can answer who changed what, and when: administrative operations are kept in a durable history and an HMAC-chained audit log, and versioned tables keep every accepted version, readable as of a commit.
Your production data has one home, yours: deployments are self-hosted, and there is no NYXDB-operated cloud that your data flows through.
Production checklist
The checks the docs ask for before go-live and in steady state, each with the route, statement or relation that confirms it.
Give every node durable local storage, then confirm the readiness probe lists the password and API-key issuers. That one answer proves the issuer key is in place.
GET /auth/issuers · password · api_keyDeploymentCreate a user for every person and every service, with the service kind for automation, and give each service its own API key with an expiry. Drop the keys you no longer use.
CREATE USER analyst KIND SERVICE PASSWORD ?;Users and API keysA new principal starts with no permission. Bind a role that grants reads on exactly the relations a principal needs, and keep read and manage permissions apart.
relation_read · relation_write · governance_readGovernanceMake the file that signs bearers readable only by the node process. It is the one secret that stands behind every password and API-key sign-in.
gateway.issuer.ed25519_private_key_fileConfigurationAfter rotating a password or dropping a key, read the credentials relation and confirm the old credential shows as disabled. The relation carries no digest, salt or secret.
system.credentialsGovernanceTransformations report healthy revisions, every stream shows its lag, and write pressure, log growth, metrics and health signals are each one read away.
system.transformation_revisions · system.psi_streams · system.storage · system.health_signalsProduction checklistIdentity
Users and keys are SQL statements; bearers, sessions and grants are state the engine keeps and you can read.
Create users and API keys with statements, the password passed as a bound parameter so it never appears in statement text or history. A key’s secret is shown once, at creation.
CREATE API KEY reporting FOR USER analyst EXPIRES IN 30 DAYS
A password or an API key is exchanged for a short-lived signed bearer, and the bearer for a session. The session token travels in the first frame of a WebSocket connection, never in a URL, a cookie or the subprotocol.
POST /auth/password → bearer → POST /auth/session
Disable or drop a key and the sessions it opened end on their next operation. Drop a user and every session of that user ends; rotate a password and the session opened with the old one ends with it.
DROP API KEY reporting FOR USER analyst
A remote instance connects with a secret minted once, and reads only the tables you grant it. Every grant carries a row predicate, so the host decides which rows leave.
read · subscribe · WHERE col = literal
If you believe you have found a security issue in NYXDB, email [email protected]. We practice coordinated disclosure: report the issue privately, give us a reasonable window to investigate and ship a fix, and we will keep you updated on progress. Please do not open a public GitHub issue for security reports.
We appreciate responsible disclosure and credit reporters who want it. A machine-readable version of this policy is published at /.well-known/security.txt.
Self-hosted deployment keeps data inside your own compliance boundary, under controls you already operate.
Audit
Administrative operations are kept in a durable journal under the data directory, and audited administrative and credential decisions land in an HMAC-chained audit log. Versioned tables keep every accepted version, so the state behind any decision is readable as it stood at that commit.
Every system relation is read with an ordinary statement, or followed as it changes, and each read needs a named permission. Read and manage permissions stay separate, so a role can read everything and change nothing.
SELECT *FROM system.query_history;Report a vulnerability or ask us about the posture above. For hardening your own deployment, the docs cover operations end to end.