ObjectOSWhy ObjectOS
The honest pitch — when you should use it, when you shouldn't, and what makes it different.
Available in
This page exists so you don't have to read between the lines of every other doc to figure out whether ObjectOS is right for you.
The shape of the bet
The ontology is the software. One executable business ontology. AI writes it, the runtime runs it, agents operate it, you own it. Four promises — and ObjectOS keeps them hosted in the browser with nothing to install (ObjectOS Cloud), self-managed on your own infrastructure (ObjectOS Enterprise), or free on your own machine (ObjectOS Community, the open-source runtime):
- Executable. Your objects, fields, relations, actions, permissions, flows and agent definitions are one typed, versioned definition that the runtime runs. REST endpoints, generated screens, RBAC, the audit log and the MCP tools are all derived from it — no code generation step, no deploy pipeline between "described" and "live".
- AI-writable. You don't hand-write that definition file by file. Describe what the business needs to the built-in AI Builder; it calls a small set of audited tools, every mutation queues for human approval, and the result is a small diff you can actually read.
- Agent-operable. Every object and every exposed action doubles as an MCP tool, so agents operate the running app under the same permissions, row-level security and audit as a person — never raw SQL, never a scraped UI.
- You own it. The ontology is ordinary ObjectStack metadata, Apache-2.0, and exporting it from either edition to run on that open-source runtime is planned. ObjectOS Enterprise also keeps the runtime and the database on your infrastructure.
That's the whole pitch. The rest of this page is who that fits and who it doesn't.
Use ObjectOS if you …
- need an internal tool, admin panel, or back-office app, and
- want the people who use it (or the AI agents acting for them) to be able to extend it without filing a ticket, and
- want it hosted and operated for you (ObjectOS Cloud) — or must run it inside your own perimeter (ObjectOS Enterprise), and
- don't want to rebuild auth + RBAC + audit + file uploads + jobs + webhooks for the tenth time.
Common scenarios where it's a fit:
| Scenario | Why it works |
|---|---|
| Replacing a Retool / Appsmith app because data sovereignty came up in security review | ObjectOS Enterprise runs in your VPC; data never leaves |
| Building a compliance / risk / vendor management tool for a regulated business | Audit log, RBAC, field security, row-level isolation are first-class — and every AI-driven change is itself an audit entry |
| Standing up an internal admin for a SaaS product | One Node process, slots in next to your existing services — or a Cloud tenant with nothing to run |
| Air-gapped or on-prem deployment for an enterprise customer | A first-class ObjectOS Enterprise target: air-gapped licenses validate offline, and the AI service can point at a local model |
| Multi-tenant internal portal (several organizations, one deployment) | A walled tenancy posture puts up the per-organization isolation wall, enforced inside the runtime — an Enterprise capability, see License & Pricing. It separates the organizations' data and memberships, not their schema: they share one database and one metadata set |
| You want your users to extend their apps by describing the change, safely | The AI Builder + HITL approval queue + audit log are the whole point |
| The long tail of departmental apps around a core ERP — vendor onboarding, inspections, internal requests | Each one is a small, typed definition that changes often, instead of a spreadsheet that gets emailed around |
| A back office that agents operate from day one | Every deployment is an MCP server, on by default; agents act through the same permissions and audit as people |
Don't use ObjectOS if you …
- need to replace the core ERP or finance system of a large enterprise → a general ledger, consolidation, tax and payroll carry regulation that packaged systems already encode. Build around that core, not instead of it.
- get your value mostly from integrating many existing systems → connecting a database you already run is read-only by default and early; a layer over those systems fits better.
- need analytics over a data lake → dashboards run over the app's own objects; they are not built to query a lake.
- work in an algorithm-heavy domain, such as pricing or scheduling → the ontology declares what can be done, not an optimiser. Wrap the algorithm as an action and permissions, audit and agent access apply to it like any other.
- must run on a platform that is itself certified → ObjectOS is not; certification is of a running deployment, and certifying yours is work you own — see Security & Compliance.
- are building a high-traffic consumer product → use a traditional web framework, you'll have more control.
- need a pixel-perfect bespoke UI for end users → the generated UI is for admin/internal use; pair it with your own front-end via REST.
- want a drag-and-drop canvas for non-engineers → use Retool, Bubble, or Airtable. ObjectOS generates its UI from the ontology; the builder is the AI and the diff it proposes, not a canvas.
- need real-time collaborative editing (Figma-style) → not what the realtime plugin solves.
The reasoning behind the first five, for the open runtime ObjectOS is built on, is on When to use ObjectStack.
Compared to what you're probably using
vs. Retool / Appsmith / Internal
| Retool | ObjectOS | |
|---|---|---|
| Data location | Their cloud (or self-hosted at higher tier) | ObjectOS Cloud, or your network on ObjectOS Enterprise |
| UI builder | Drag-and-drop, very polished | Metadata-driven, generated; less custom |
| Pricing | Per-user, scales painfully | AI seats only; viewers free. Free self-hosting is the open-source ObjectStack runtime |
| Workflow / triggers | Their workflow engine | Declarative flows + plugins |
| Backend logic | Limited to their query editor | Full TypeScript, full Node ecosystem |
| Best for | Quick dashboards on top of existing APIs | Apps whose definition you own |
vs. Supabase / Firebase
| Supabase | ObjectOS | |
|---|---|---|
| Setup time | ~30 seconds | ~30 seconds |
| Database | Postgres, theirs (self-host possible) | Managed on ObjectOS Cloud; any Postgres / MySQL / SQLite / Turso / Mongo, yours, on ObjectOS Enterprise |
| Auth | Built in | Built in |
| Generated APIs | PostgREST | ObjectQL-generated REST |
| Admin UI | Console (basic) | Setup + Account |
| RBAC | Row-level via Postgres RLS | RBAC + row-level + field-level, declarative |
| Audit log | DIY | First-class |
| Vendor lock-in | Their auth + their storage + their realtime | The ontology is ordinary ObjectStack metadata, with export to the open-source runtime planned; every layer is a plugin |
| Best for | New apps that want a BaaS | Apps that need to own their definition — and, on Enterprise, their runtime |
vs. Salesforce / NetSuite / ServiceNow
| Salesforce | ObjectOS | |
|---|---|---|
| Data model | Objects + fields + relationships, configured in the platform | Objects, fields and relations in one open ontology — ordinary metadata for the Apache-2.0 ObjectStack runtime, with export planned |
| Permissions | Profile + permission sets + sharing rules + FLS | A familiar vocabulary — permission sets, positions, sharing rules, FLS — declared in the ontology and enforced on every REST call, UI click and agent tool call |
| Per-user cost | $150-300/user/month | Viewers and non-AI users free; you pay for AI seats only |
| Customization | Apex + Lightning + flows | TypeScript + flows |
| Where it runs | Their cloud, period | ObjectOS Cloud, or your infrastructure (ObjectOS Enterprise) |
| Time to "we own it" | Months of consultant work | One afternoon |
| Best for | Sales-led companies who'll pay for the ecosystem | Teams who want the model without the tax |
vs. rolling your own (Next.js + Prisma + NextAuth)
| DIY | ObjectOS | |
|---|---|---|
| First REST endpoint | A few hours | 60 seconds |
| Auth (email + OAuth + OIDC + passkey + 2FA) | Weeks | Included |
| Admin UI for every object | Build per object | Generated |
| Audit log | DIY | Plugin, declarative |
| File upload to S3 with permissions | DIY | Plugin |
| Background jobs + retries + dead letter | DIY | Plugin |
| Multi-tenancy | DIY (and you'll get it wrong twice) | Built in |
| Best for | Public-facing app with bespoke UX | Internal tooling where speed wins |
The honest tradeoffs
- Less UI freedom than Retool. The UI is generated from your metadata. You can pair it with a custom front-end (the REST API is the same one the UI uses), but if you need a hand-crafted pixel- perfect UI, build it yourself and use ObjectOS as the backend.
- TypeScript-first. Non-engineers won't author objects directly in a
repo. Salesforce admins are used to clicking through a UI builder; here,
it's the AI Builder's diff or
git. - Newer than Salesforce. Salesforce has 25 years of edge cases documented. We have a few hundred. The protocol is stable; the ecosystem is growing.
- Open-source foundation, three editions. The underlying ObjectStack stack is Apache-2.0 — use it in commercial products, embed it, modify it privately, no copyleft surprises. ObjectOS Community, the open-source runtime and Console built from it, is free under the same license; ObjectOS Cloud and ObjectOS Enterprise are the commercial editions, adding hosting and operations, the AI Builder, SSO and support.
Reality check
The smallest ObjectOS is a Free tenant on ObjectOS Cloud; the smallest self-managed one is a single-node container with SQLite. The largest in production today serves tens of thousands of internal users across multiple regions with Postgres + S3 + Redis. All of them run the same software.
Start on ObjectOS Cloud, or scaffold a project
on ObjectOS Community with npm create objectstack@latest my-app,
and decide in 5 minutes. If it's not for you, you've burned 5 minutes.
Introduction
ObjectOS Community is free and self-hosted, ObjectOS Cloud the hosted edition, ObjectOS Enterprise the self-managed, licensed one. You own the ontology.
Your ontology in ObjectOS
What your ontology is on ObjectOS — the core the runtime runs, the projections authored beside it, where it lives, and what it is not.