Skip to content

Core platform

Core platform

Core is Norbital's managed control plane. It hosts pod workspace source, runs sandboxed builds when builders commit or merge to live, provisions per-tenant databases, and serves live and preview environments. Core runs the same @norbital-ai/pod runtime — it adds hosted plugins, product UI, and managed operations on top.

Pod defines the workspace; Core hosts it
Everything in the Pod docs describes the authoring SDK and runtime. This section documents what the managed platform adds.

Core plugins

Two capabilities are Core-only — they are not shipped inside @norbital-ai/pod:

  • Workspace Studio — browser UI for editing workspace source, releasing checkpoints, and managing org settings (Workspace Studio docs)
  • Agent — in-workspace AI assistant with metered usage, under the same ACLs as tenant apps (Agent docs)

Builders ship changes through Workspace Studio — Commit (preview sync) and Merge to live — they do not run their own deploy pipeline.

Checkpoints & releases

Checkpoints are immutable workspace builds produced by Workspace Studio release actions. A successful preview sync or merge-to-live creates a checkpoint — a frozen bundle stored in Core's artifact store. See Workspace Studio for the Review tab, toolbar controls, and rollback flow.

Deploy zones

  • Edit — mutable source in Workspace Studio (preview branches only)
  • Preview — latest built checkpoint for the branch (branch_db_map) + preview tenant database
  • Production — live checkpoint (tenant_workspace_head) + live tenant database

What a checkpoint contains

  • output/server/ — collection, hook, automation, and remote runtime bundle
  • .norbital/migrations/ and schema SQL — incremental tenant migrations
  • dist/ — compiled tenant apps, assets, and runtime host shim

Checkpoints are immutable. A new Commit or merge-to-live creates a new checkpoint; it does not mutate an old one.

Release steps

  1. Edit — persist source changes in a preview branch worktree (no build, no DDL)
  2. Commit — Vite build in a sandbox, apply preview DDL, record checkpoint in branch_db_map
  3. Verify — exercise tenant apps and policies against preview data
  4. Merge to live — replay migration bundles on production DB, advance tenant_workspace_head
Edit is not apply
Database schema and automation schedules change on Commit and Merge to live — not when you save draft source in the editor buffer.

Migrations

Build emits additive DDL by default. Destructive schema changes may require an explicit supplement SQL script before preview sync completes. Merge to live replays accumulated bundles on the production database; Core takes a pre-migrate dump for rollback safety.

Rollback

Production can be rolled back to a prior checkpoint from Workspace Studio's Review tab: restore manifest artifacts, align production DDL, record a new checkpoint for audit. Preview is not rolled back — Commit again from your branch if preview drifted ahead.

What Core provides

  • Source store — versioned workspace source in object storage
  • Build orchestration — ephemeral sandboxes run vite build on Commit and merge-to-live, stream checkpoint to artifact store, destroy box
  • Checkpoint registry — system database tracks live head (tenant_workspace_head), per-branch preview builds (branch_db_map), and rollback history
  • Tenant databases — provisions isolated Postgres per org; applies DDL at Commit and merge-to-live
  • Runtime sidecar — warm isolate pool per checkpoint; binds db, storage, AI, secrets into guest
  • Auth & orgs — Better Auth, email OTP, team invitations, impersonation
  • Billing — Builder / Executive / User seat licenses plus metered storage and AI
  • Workspace Studio — browser UI for source edit, checkpoint release, people, policies, billing

What Core does not own

Core imports no pod TypeScript internals. It does not embed tenant logic directly. Collection operations proxy through host.invoke into the pod runtime where policies and SQL are evaluated.

Policy evaluation, approval gates, and SQL compilation always run inside the pod guest.

Organization lifecycle on Core

  1. Signup — create organization stub and admin auth user
  2. Onboarding — workspace details → Stripe billing trial → managed database provision
  3. Author — builders edit source in Workspace Studio
  4. Release — Commit → verify → merge to live (or rollback)
  5. Operate — users run tenant apps; executives use Agent; builders ship checkpoints

Two-database model

  • System DB — organizations, auth sessions, checkpoint metadata, billing
  • Tenant DB — per-org Postgres with collection data, policies, approvals, app records

Core authenticates against the system DB, then proxies collection reads and writes into the tenant DB through the pod runtime.

Seat types

  • Builder — Workspace Studio authoring, Commit, merge to live
  • Executive — tenant apps + Agent, no builder access
  • User — tenant apps only

See pricing for Core seat fees and metered usage.