Orgs and instances
Shipped
Two objects structure everything in the console: organizations own instances.
Organizations
Section titled “Organizations”An organization (org) is the ownership and billing boundary. It owns instances, holds members, and is where invoices and payment methods live.
- Create an org at
/orgs/new. The console suggests a URL-safe slug from the name, and asks for a contact email; a website and a phone number are optional. Your own role is shown but not yours to pick — the first member of a new org is always its admin. - Switch orgs from the nav. Your active org scopes the create-instance form and the billing views.
- Settings — an org admin can rename the org from its settings page. Any member can leave an org from the same page — except the last admin, who must promote another member to admin first so the org isn’t left unmanageable.
A newly self-signed-up org starts disabled until Turbobase staff enable it. You can still create an instance in the meantime — it keeps your slug claim and parks with a New (no access) badge and an Awaiting approval note while you wait. Once the org is enabled the badge becomes Pending, and an instance admin gets a Start Provisioning button on the row — or Launch instance on the instance’s provisioning page, under “Your organization is approved”.
Members and access
Section titled “Members and access”Manage who can do what from the org’s Members & Access page (admin-only):
- Org roles — each member is an org admin or viewer. Admins manage members, invitations, and org settings; viewers are read-only (they can list the org’s instances and open usage, but can’t change anything).
- Per-instance roles — separately from the org role, each member can hold a role on each instance: admin (manage the instance’s config and team, delete it), developer (work with the instance’s data, not its config), or viewer (read-only). The page lists one row per member; the Instance access cell summarises what they hold and expands to a line per instance, each with its own role picker — No access, viewer, developer or admin.
- Manage instances — managing the org is separate from being allowed to spin up (or tear down) production. Creating or deleting an instance needs this org-level permission, a checkbox on the member’s row that an org admin ticks explicitly; being an org admin alone doesn’t confer it.
- Scoped invites — when inviting a teammate, you pick their org role and a per-instance role for each existing instance (defaulting to no access), so the grants land the moment they accept.
- Guards — the console blocks changes that would lock you out: you can’t suspend or remove the last active org admin, and you can’t untick Manage instances on yourself when you’re its last holder. Member and access changes are recorded in the org’s audit log, shown on the same page.
Instances
Section titled “Instances”An instance is one provisioned Turbobase environment — its own dedicated Postgres database and its own app at <slug>.turbobase.app. Each instance belongs to exactly one org.
- Create at
/instances/new, scoped to your active org. Pick a name; the slug becomes your subdomain. Instances are hosted in our US East (Ashburn) region — the single location on offer today, so there’s no region picker. The plan selector shows the tiers, but it’s locked while pricing is finalized: every new instance is created on the entry plan, Ignition. - List at
/instances, grouped by org. Each row shows the instance’s live status and the one action that state allows while it’s still being set up: Start Provisioning (approved and waiting on you), Resume (provisioning already under way), Set-up (run the wizard) or View failure. - The instance’s slug is the link that opens your Turbobase app, in a new tab. It only becomes a link once setup is finalized; before that it’s plain text and the row points you back into the setup wizard.
- Connections on a finalized row opens that instance’s connections screen. Every system you’ve connected has a row there, and you can pause one — which stops it syncing in both directions until you resume it — or remove it, which permanently deletes the records it brought in. Add sources covers both in full.
- Usage and Delete are icon buttons rather than labelled ones — Delete is the trash glyph. Hover either one to see its name.
- Delete is self-service but deliberately guarded: you must hold the admin role on that instance and Manage instances on the org, and you confirm by typing the instance’s slug exactly into the confirmation modal. Teardown then runs asynchronously — the instance shows Deleting… until it’s gone.
Provisioning status
Section titled “Provisioning status”Instance status moves through a small set of stages. The console renders each one as a friendly label and color (green = ready, amber = in-flight, red = needs attention, gray = neutral). The states you may see:
| Console label | Meaning |
|---|---|
| New (no access) | Created against a not-yet-enabled org; parked with an Awaiting approval note until staff enable it |
| Pending | Your org is enabled and the instance is yours to start — Start Provisioning on the row, or Launch instance on its provisioning page |
| Provisioning… | Work has started |
| Provisioning… (database) | Building your dedicated database schema |
| Provisioning… (services) | Deploying the instance’s app and sync services |
| Provisioning… (waiting for health checks) | Waiting for everything to report healthy |
| Ready | Live; ready for setup / use |
| Paused | Suspended |
| Failed | Provisioning failed — contact support |
| Upgrading… (with a database / services qualifier) | A version upgrade is in flight |
| Upgrade failed | An upgrade didn’t complete — contact support |
| Deleting… | Teardown in progress |
| Deleted | Terminal — the instance is gone |
The happy path runs Provisioning… → database → services → health checks → Ready. From Ready an instance can later move into an upgrade, into Paused, or into Deleting → Deleted. A failure during provisioning shows Failed; a failure during an upgrade shows Upgrade failed.
Reaching Ready doesn’t mean setup is done — a Ready instance still needs the setup wizard run before its app opens. That’s why a Ready row keeps its Set-up button until the wizard is finalized, and only then does its slug become a link.
Related
Section titled “Related”- Provision your instance — the step-by-step create flow.
- Add sources — connect more systems to a live instance.
- Billing and usage — what each org is consuming and owes.