What technologies power the KBVE API?

The API is written in Rust (axum-kbve) with Python tooling and a SQL database, and it builds on Supabase, Strapi, and Appwrite as reference frameworks for the multi-tenant surface.

axum-kbve · multi-tenant

The central KBVE API

Q: What is the KBVE API?

The KBVE API is the central multi-tenant API for KBVE projects, implemented as the axum-kbve Rust service. It exposes shared endpoints for auth and data and is built on Supabase, with reference documentation aimed at onboarding new developers.

Q: How is the KBVE API deployed?

It runs in production in the kbve namespace as the kbve/kbve image, deployed via apps/kube/kbve/manifest/kbve-deployment.yaml, with an axum-kbve-e2e test suite gating releases.

A Rust / axum service with Supabase-backed auth and a SQL database. One shared surface for every KBVE project — built on Supabase, Strapi, and Appwrite as reference frameworks.

View on GitHub

Reference Locker

Reference scope

Written in Rust and Python, database in SQL. Holds the general reference points for the multi-tenant API — expanding over time to make onboarding new developers easier.

Rustaxum-kbve

Multi-tenantShared surface

SupabaseAuth + JWT

Prodkbve namespace

Auth

JWT is the key between the $User and the $API. The core auth mod ships register + login with generic defensive components baked in, then layers external security — rate limits and firewalls, some operating outside the API.

Cookie token — stores the client $User JWT.
Cookie user — stores the client $User data.
react-cookie maintains the cookie lifecycle.
Appwrite JWT held in a Nanostores session store.

API Keys

API keys are unique identifiers that authenticate requests without exposing user passwords — special passwords generated for the software, keeping credentials confidential while proving the caller is authorized.

v0 — current storage carries encryption risks slated for migration.

Install

The current install pipeline is queued for migration. Front-end instances ship as applications or static pages, with occasional SSR / hybrid edge cases.

Proxmox → qEMU → Docker Swarm.
Portainer deploys the image.
v1 — see the Appwrite documentation for the next-gen path.

Uptime

Uptime is the heartbeat of the API. Consistent availability is monitored in real time; even minor downtime erodes trust. Handled today by ChecklyHQ, with a home-grown NodePy hourly checker planned down the line.

Checkly badge tracks response time + status.
Future — NodePy runs automated hourly test cases.

A personal vault in the browser

Client-side storage for variables and data points that never need to hit the main server — fast, offline-capable, with locking to guard against concurrent modification. Combination known only to trusted sources.

Managed with Nanostores.
Optional AES encryption over stored values — planned for early next year.
In use since August 12th, 2023; extendable as needed.

kbveLocker

export type kbveLocker = {
  username: string;
  phone: string;
  last: string;
  uuid: string;
  avatar: string;
  github: string;
  instagram: string;
  email: string;
  theme: 'dark' | 'light' | 'auto';
};

What is the KBVE API?

The central multi-tenant API for KBVE projects, implemented as the axum-kbve Rust service. It exposes shared endpoints for auth and data, built on Supabase, with reference docs aimed at onboarding new developers.

What technologies power it?

Rust (axum-kbve) with Python tooling and a SQL database, building on Supabase, Strapi, and Appwrite as reference frameworks for the multi-tenant surface.

How is it deployed?

In production in the kbve namespace as the kbve/kbve image, deployed via apps/kube/kbve/manifest/kbve-deployment.yaml, with an axum-kbve-e2e suite gating releases.