Nubase
Get started

The eight modules

Nubase is built around eight modules that take an AI-written app from data all the way to a live URL. They're peers — not features bolted onto a database — and they share one authentication model, one tenant boundary, and one self-hostable runtime.

Why these eight

Traditional BaaS (Supabase, Firebase, AWS Amplify) gives you three: Database · Storage · Auth. That was enough when apps were CRUD-on-data. AI-native apps add Memory (durable, queryable knowledge) and an AI Gateway (model routing). And to actually ship a generated app you need the deploy layer too: Assets to publish the frontend, Functions to run backend logic, and cron to schedule recurring work — so an agent goes generate → live without stitching three services together.

Database

A real PostgreSQL per tenant. Your app speaks SQL — directly or via the generated REST API.

Owns

  • ·public.* — your business tables
  • ·auth.users / auth.sessions / auth.refresh_tokens — identity tables
  • ·Per-tenant Postgres roles (service_role · authenticated · anon)

Key endpoints

  • ·GET /rest/v1/{table} — PostgREST-compatible: select / filter / order / limit
  • ·POST /rest/v1/{table} — insert
  • ·PATCH /rest/v1/{table}?id=eq.X — update
  • ·POST /auth/v1/admin/sql/execute — service-role only

Auth

Issues the two-layer JWT used by every other module. Supabase-compatible API surface.

Owns

  • ·Tenant apikey: signs with per-tenant secret, carries the ref claim
  • ·User Bearer token: carries sub + role, RLS reads via auth.uid()
  • ·OAuth identities (auth.identities) + email/password

Key endpoints

  • ·POST /auth/v1/signup — create user
  • ·POST /auth/v1/token — sign in, get access + refresh
  • ·POST /auth/v1/token?grant_type=refresh_token — rotate
  • ·GET /auth/v1/authorize?provider=google — OAuth start

Storage

S3-compatible object storage with metadata in your Postgres so ACLs are RLS-aware.

Owns

  • ·storage.buckets — bucket metadata (public / private, size limits)
  • ·storage.objects — file metadata + RLS policies
  • ·Object bytes live in S3 / R2 / MinIO — bring your own bucket

Key endpoints

  • ·POST /storage/v1/bucket — create bucket
  • ·POST /storage/v1/object/{bucketId}/{path} — upload
  • ·GET /storage/v1/object/sign/{bucketId}/{path} — signed URL

Assets

A public CDN for the generated frontend — upload static files, get a live URL. No separate static host.

Owns

  • ·assets.files — asset metadata (path, etag, cache policy)
  • ·assets.settings — per-project delivery + optional custom domain
  • ·Bytes in R2 (CDN mode) or the global Storage bucket (backend mode)

Key endpoints

  • ·PUT /assets/admin/v1/files/{path} — publish (service_role)
  • ·GET /assets/v1/{path} — public read (tenant from subdomain)
  • ·MCP assets_upload / assets_list / assets_delete

Functions

Deploy AI-written backend logic as edge functions behind the Nubase gateway.

Owns

  • ·edge_functions / edge_function_versions — deploys + version history
  • ·edge_function_secrets — encrypted per-function secrets
  • ·edge_function_invocations — invocation logs

Key endpoints

  • ·POST /functions/admin/v1/functions/{slug}/deploy — deploy
  • ·ANY /functions/v1/{slug} — invoke (verify_jwt)
  • ·MCP functions_deploy / functions_invoke / functions_secrets_set

AI Gateway

OpenAI/Anthropic-compatible model routing with per-project keys and usage tracking.

Owns

  • ·Gateway nbk_ keys (hashed) per project
  • ·Per-request usage: tokens, cost, first-token latency
  • ·Model pricing table for cost analytics

Key endpoints

  • ·POST /v1/messages — Anthropic-compatible
  • ·POST /v1/chat/completions — OpenAI-compatible
  • ·GET /ai-gateway/admin/v1/usage/overview — analytics

Memory

Durable knowledge about each user that the LLM can read and write — the layer plain BaaS lacks.

Owns

  • ·mem.memories — facts with embeddings + audit hash
  • ·mem.memory_history — append-only ADD/UPDATE/DELETE log
  • ·mem.entities — entity store with linked memory ids for retrieval boost
  • ·mem.session_messages — rolling short-term conversation window

Key endpoints

  • ·POST /mem/v1/memories — write (LLM extracts facts and decides ADD/UPDATE/DELETE)
  • ·POST /mem/v1/search — vector + BM25 + entity-boost fusion
  • ·GET /mem/v1/memories/{id}/history — audit trail
  • ·GET /mem/v1/entities — manage extracted entities

cron

Recurring jobs from the control plane — invoke a function or a db function on a schedule.

Owns

  • ·scheduled_jobs — schedule, target, next_run_at / locked_until
  • ·scheduled_job_runs — run history
  • ·Control-plane scheduler with a row-level claim (no double-run)

Key endpoints

  • ·POST /cron/admin/v1/jobs — create (service_role)
  • ·GET /cron/admin/v1/jobs/{name}/runs — run history
  • ·MCP cron_create / cron_update / cron_runs

How they fit together

  1. One request, two JWTs. Every API call carries an apikey header (tenant + role) and an optional Authorization: Bearer (end user). The first picks the database; the second picks the user. Generated frontend code uses the anon key; service_role stays server-side.
  2. One tenant boundary. Memory, auth, storage metadata, assets, functions and your business tables all belong to the same tenant. A breach of one tenant's secret cannot cross.
  3. One RLS philosophy. Database tables enforce RLS at the Postgres level via SET LOCAL ROLE. Memory enforces ownership in the service layer via MemoryAuthScope. Both refuse cross-user reads by default.
  4. One deploy surface. The same project token and MCP tools that read your data also publish the frontend (Assets), deploy backend logic (Functions) and schedule jobs (cron) — generate → live from one place.

Next

  • Quickstart — stand up a backend, create a project, and deploy.
  • Memory guide — the differentiating module, in depth.