platform engineering

How axyvera.com itself is built

This page is about the commercial website and license backend you're reading right now — not the Axyvera product. It's here so a security reviewer can see the whole stack, honestly.

read this first
The Axyvera product is local-first: it runs on your machine, has no server, and stores no session content. Everything below — databases, caching, hosting, scaling — belongs to this website and its license API only. For how the product works, see architecture.
System architecture

Stateless functions on the edge

Next.js 16 (App Router) on Vercel. Marketing pages are statically prerendered; the API runs as stateless serverless functions behind a single Store abstraction.

next 16 · app router
APIs & backend logic

Typed handlers, validated input

Every route is a typed handler with zod-validated input and a uniform response envelope. Issuance signs licenses; validation verifies them and reports revocation.

app/api/* · zod
Databases & storage

One interface, two backends

A Store interface with a durable FileStore for dev and an Upstash Redis (KV) adapter for production — over fetch, no client library. It holds issued licenses, access requests, staff accounts (scrypt-hashed), and session hashes; nothing else.

lib/store.ts
Auth & permissions

Self-hosted staff sign-in

Staff sign in with email + password — scrypt-hashed, verified in constant time, over an httpOnly SameSite=Strict session cookie. Built on node:crypto with no auth vendor; every issue and revoke is attributed to the signed-in admin.

lib/auth/* · scrypt · sessions
Security

CSP and hardening headers

Content-Security-Policy, HSTS, nosniff, Referrer-Policy, Permissions-Policy, and frame denial on every response. CI scans the full git history for leaked secrets on every push; licenses verify offline.

next.config.ts · gitleaks
Rate limiting

Token bucket, KV-backed

An in-memory token bucket per client and route, with a KV-backed mode so limits hold across serverless instances. Over-limit returns 429 with Retry-After.

lib/ratelimit.ts
Caching & CDN

Static at the edge, no-store for APIs

Marketing routes are prerendered and served from Vercel's CDN; API responses set Cache-Control: no-store so nothing sensitive is ever cached.

edge · cache-control
Error tracking & logs

Structured logs with request ids

Every request gets a correlation id, a structured JSON access-log line, and an x-request-id header. A pluggable error hook forwards failures to a service if configured.

lib/logger.ts · handler.ts
Monitoring & alerts

Liveness and readiness

A health endpoint reports config presence and build id; a readiness endpoint confirms the datastore is reachable before traffic is served. An env-gated hook drives alerts.

/api/health · /api/ready
Testing

Typecheck, unit, and interop

vitest covers the license core, routes, store selection, headers, and rate limiting; a cross-language test proves Node-signed licenses verify under the product's Python verifier.

vitest · pytest interop
CI/CD & version control

Green-only on every push

A GitHub Actions workflow runs typecheck, tests, a production build, and a full-history secret scan on changes to the site. The build succeeds without any runtime secret.

.github/workflows
Scaling

Horizontal by design

Because functions are stateless and state lives in an external store, the site scales out horizontally with no sticky sessions or shared local disk.

stateless · external store
what you won't find here
No Postgres, no row-level security, no VPC — and that is deliberate, not an omission. There is no relational database to lock down: state is one small KV/file store holding licenses, requests, staff accounts (hashed), and session hashes. If the data model ever outgrows that, the upgrade path is Postgres with RLS — we would rather document that honestly than claim controls that do not exist.
verify it yourself

The claims above map to code and to live endpoints. Liveness is at /api/health, readiness at /api/ready, and the validation API is documented in the API reference.