Verixa

Verixa is open-source infrastructure for authentication, authorization, identity, verification, audit logging, security, and governance — built to be production-ready and, at the same time, a complete educational resource for learning backend engineering, software architecture, and security best practices.

Every subsystem (credentials, sessions, RBAC, audit logging, etc.) is designed as an independently testable, independently reusable module under packages/, composed together by the HTTP API in apps/api.

Status: early, but running. Registration, login, account lockout, email verification and password reset work end to end against Postgres, and the audit log is anchored to Stellar. 70 of 500 planned issues are complete — see Roadmap. Sessions (Phase 05) are the next milestone and the current limitation: login authenticates a user but does not yet issue a token.

Why Verixa

Most auth/identity building blocks are either a SaaS you pay for and can't audit, or a snippet you copy-paste and never fully understand. Verixa aims to be neither: a codebase you can read end to end, run yourself, and learn real architecture and security practice from — while still being solid enough to build on.

Verifiable audit logging on Stellar

Verixa's audit log is hash-chained — every entry commits to its predecessor, so altering or removing one breaks every hash after it.

That alone is weaker than it sounds, and Verixa says so rather than claiming otherwise. An attacker with write access to the database can rewrite the chain from any point and re-derive every subsequent hash; the result is internally consistent and indistinguishable from the truth. Hash chaining makes a log tamper-evident to someone already holding an earlier hash. It does not make it tamper-proof.

Stellar is what closes that gap. The chain's head hash is committed to a Stellar transaction's MEMO_HASH — 32 bytes, exactly the size of a SHA-256 digest, so the hash goes in whole. Rewriting history now also requires altering a public ledger the operator does not control.

The property that matters is independent verifiability: an auditor, a regulator, or a suspicious user can check the log against the ledger with no access to, and no trust in, the operator's systems.

Try it — no database, no configuration

pnpm install
pnpm --filter @verixa/audit demo

(The demo builds the packages it needs first, so this is genuinely the whole setup — no database, no keys, no .env.)

It funds a throwaway testnet account from friendbot, records audit events, chains them, anchors the head, then verifies the commitment by reading it back off the ledger the way a third party would — and confirms a tampered hash is rejected.

A real run:

4. Anchoring the chain head to Stellar
   transaction: 21267a74f69d019fa40c1f93a6953896113ae2ee0e62af35326852a86a07d775
   covers:      3 entries, through sequence 3

5. Verifying the commitment from the public ledger
   ledger commits to the head hash: true

6. Confirming a tampered hash is rejected
   altered hash verifies: false  (must be false)

That transaction is on the public testnet ledger: stellar.expert — its memo is the audit log's head hash.

Only the hash

Audit content never leaves the operator's database. Audit records are exactly the records most likely to contain something sensitive, and a public ledger is irreversible. A digest proves the records existed unchanged while revealing nothing about them.

Honest scope

• Testnet today. Mainnet needs KMS-backed key management, funding and balance monitoring, and a rehearsed cutover — tracked as issues 190B–190D and not yet done.
• Anchoring is scheduled, not per-entry. A transaction per login would cost a fee and seconds each time and buy little, since the chain already links entries; anchoring the head commits to everything beneath it. How often is the operator's knob, and it bounds the window for undetected tampering.
• Ledger-agnostic by construction. Nothing above the adapter mentions Stellar. HashAnchor is the port; StellarHashAnchor is one implementation.

See docs/adr/0003-stellar-audit-anchoring.md for the full rationale.

Architecture

Verixa is a TypeScript pnpm-workspaces monorepo following Clean Architecture and Domain-Driven Design: domain logic has no dependency on frameworks or databases, and each bounded context (identity, credentials, sessions, authorization, verification, audit, governance, notifications) lives in its own package.

Full details: docs/adr/0001-monorepo-and-stack.md records the stack decision; a broader architecture guide will grow under docs/ as more contexts are built. Every non-trivial architectural decision from here on gets its own ADR — see docs/adr/0000-adr-process.md for the process.

verixa/
├── apps/api/        # Fastify HTTP app (composition root)
├── packages/        # Bounded-context packages (domain/application/infrastructure/interface)
├── infra/           # Deployment & infrastructure config
├── docs/            # Guides, ADRs, tutorials
└── tests/           # Cross-package integration/e2e tests

Prerequisites

• Node.js 22.13 or later (required by pnpm 11)
• pnpm 11 or later (npm install -g pnpm)

Quickstart

pnpm install
pnpm --filter @verixa/api dev

pnpm install also generates the Prisma client, which is platform-specific and therefore never committed — see docs/guides/database.md.

The API starts on http://localhost:3000 (override with PORT). Verify it's up:

curl http://localhost:3000/health
# {"status":"ok"}

Prefer one command and don't want Node/pnpm installed locally at all? Run the full stack (API + Postgres + Redis) in Docker instead:

docker compose up

See docs/guides/docker.md for details, including the production image (apps/api/Dockerfile), which is a separate, intentionally different thing from the dev compose stack.

Other useful commands, run from the repo root:

pnpm build       # build all workspace packages
pnpm typecheck   # typecheck all workspace packages
pnpm test        # run all unit/integration tests
pnpm lint        # lint the whole workspace
pnpm format      # auto-fix formatting with Prettier

See docs/guides/code-style.md for what the linter checks and why.

Contributing

Verixa isn't yet open for external contribution — the initial architecture and foundational tooling are still being laid down. See CONTRIBUTING.md for the local developer workflow so far. A CODE_OF_CONDUCT.md and issue/PR templates will land as part of the roadmap before the project accepts outside contributions.

License

MIT — see NOTICE for third-party attributions and docs/guides/licensing.md for why MIT.