Steedos Platform: metadata-driven enterprise apps on the ObjectStack architecture

What Steedos Platform actually solves for enterprise app teams

Most internal business software is a schema, a set of permissions, a workflow and a form. Writing those four things by hand in a general-purpose framework is repetitive, and the result is usually hard for anyone outside the original author to change. Steedos Platform takes the position that all four should be described as metadata, and that the metadata should be plain text so a language model can produce it.

The README frames this as "Metadata is the new Code" and describes a Universal Metadata Standard called ObjectQL that "allows AI to generate complex applications instantly." Concretely, the repository documents two metadata file types: `*.object.yml` for data models and `*.page.yml` for pages. The pitch is that you describe a business need in a prompt, the model emits those files, and the runtime turns them into APIs and screens.

The audience is therefore narrower than the low-code topic list suggests. This is not aimed at a business analyst who wants to drag boxes around a canvas. It is aimed at a developer or platform team that is willing to keep schemas in Git, review them in pull requests, and treat the visual builder as one consumer of the metadata rather than the source of truth.

The ObjectQL, ObjectOS and Object UI split

The architecture is described as three independent pillars. ObjectQL is the protocol: a unified language for defining data, logic and UI, positioned as the interface between an AI and the software. ObjectOS is the engine: a headless runtime kernel that provides APIs, authentication, permissions and workflow automation. Object UI is the renderer: a schema-driven front end built on React and Tailwind that turns metadata into pages.

The data flow implied by that split is one-directional. Metadata files are the input. ObjectOS reads them, exposes GraphQL and REST APIs for every model, and applies role-based access control down to the field level. Object UI reads the page metadata and renders it. Because the UI is a separate consumer, a custom React component can be injected into a standard page layout without forking the renderer, and the same metadata can in principle be served to a different front end.

The README also claims the data layer is database agnostic, with the same metadata deployable to MongoDB, PostgreSQL or simple JSON files. That is a real architectural commitment, not a marketing line, because it forces the query layer to be an abstraction rather than raw SQL. The cost is that anything the abstraction does not model becomes awkward, and the README does not document which database-specific features are unavailable. If your application depends on a particular index type or a database-specific query construct, verify it against the ORM before you commit.

Installing Steedos Platform and generating a first object

There are two documented paths. The fastest is the published Docker image, which the README describes as the latest stable version before the ObjectStack transition is complete. It maps port 80 and needs no local toolchain.

docker run -d -p 80:80 steedos/steedos-community:3.0

After the container starts, the platform is reachable on port 80 of the host. Expect a first-run setup rather than an empty shell; the README does not describe the initial account flow, so treat that as something to discover in the running instance.

The second path scaffolds a project from source. This is the one to use if you intend to write metadata by hand and keep it in version control.

npx create-steedos-app my-app
cd my-app
yarn install && yarn start

The README states the app is then available at `http://localhost:5100`. Note the two different ports: the Docker image serves on 80, the scaffolded app on 5100. That mismatch is worth remembering when you write deployment scripts.

Working from the monorepo itself is a third option, and it has a hard prerequisite. The root `package.json` sets `"engines": { "node": ">=22.0.0" }` and pins the package manager to `yarn@3.8.7`, so a Node 20 machine will not satisfy the declared engine range. The root scripts are the entry points: `yarn start` changes into `builder6/server` and starts it, `yarn webapp` runs the front-end dev server from `builder6/webapp`, and `yarn docker:db` brings up only the backing services (mongodb, mongodb-init, redis and nats) without the application. There is also a Moleculer REPL script, `yarn repl`, which loads `steedos.config.js` and drops you into an interactive runner. Once inside, the object metadata you write is the artifact that matters: an `*.object.yml` file defines fields, and ObjectOS derives the REST and GraphQL endpoints from it.

Where Steedos Platform is the wrong choice

The clearest limitation is stated by the project itself. A banner near the top of the README says the platform is migrating to ObjectStack, that the core is being refactored into ObjectQL, ObjectOS and Object UI, and that "while Steedos Platform v2.x remains supported, future development is focused on the ObjectStack ecosystem." That is a maintenance signal you have to price in. The last push to the repository was on 2026-09-14, so the code is moving, but the direction of travel is away from the monorepo you would be adopting.

The release history reinforces the split. The most recent listed release is v2.7.32 from 2026-02-04, while the 3.0 line appears as v3.0.10 (2025-12-30) and v3.0.11-beta.4 (2026-01-06). A stable 2.x line and a beta 3.0 line sitting alongside each other, with the README pointing at a third set of packages, means the question "which version am I building on" has no single answer from the documentation alone.

There is also a licence boundary. The README badge says MIT, but the repository licence is AGPL-3.0 and the licence file is `LICENSE.txt`. Those two statements do not agree, and the discrepancy matters more for a server product than for a library, because AGPL-3.0 reaches network use. If you plan to host a modified Steedos instance for external users, the licence question is not cosmetic. Resolve it by reading `LICENSE.txt` in the tree you actually deploy, and take legal advice rather than treating either badge as authoritative.

Finally, this is not a good fit for a team that wants a stable API contract with a long deprecation window. A platform in the middle of an architectural refactor will move under you.

How Steedos Platform differs from Airtable and Budibase

The repository's own topic list places it next to Airtable, Budibase, Appsmith and ClickPaaS, so the comparison is fair to make. The difference is where the source of truth lives.

Airtable is a hosted database with a grid interface, and its schema is edited in that interface. Budibase is an open source low-code builder where you assemble screens in a visual editor and the app definition is the builder's output. In both cases the primary authoring surface is a UI, and the artifact is something the tool owns.

Steedos inverts that. The README describes metadata as the input and the UI as a schema-driven renderer, with page layout generated from `*.page.yml` rather than hard-coded. The intended author is a model or a developer editing YAML, not someone dragging components. Whether that is an advantage depends entirely on your team: a text-first schema is reviewable in a diff and generatable by an LLM, but it is a worse experience for a non-technical operator who wants to change a field label on a Friday afternoon.

The second difference is deployment. The README contrasts ObjectStack's "anywhere (Edge/Server)" deployment with Salesforce's cloud-only model and describes the platform as microservices ready, with services communicating over standard protocols. The repository layout supports that claim: `services/*`, `packages/*`, `ee/*` and `builder6/*` are separate workspaces under one Lerna root, and the Moleculer runner is the process host. A monorepo with independent service packages is a different operational shape from a single Node application, and it is more work to run.

Maintenance, upgrade cost and the AGPL-3.0 question

The repository is not archived and the last push was on 2026-09-14, so development is ongoing. The upgrade cost comes from three places rather than one.

First, the monorepo tooling. The root uses Lerna 9 with Yarn 3.8.7 workspaces and requires Node 22 or newer. Release scripts include `release:beta` (a forced Lerna publish to the beta dist-tag on the public npm registry) and `release:again` (a `from-package` publish). If you consume the published packages rather than the source, your upgrade cadence is set by those publishes, and the beta tag is a real channel you can accidentally land on.

Second, the metadata contract. Moving from Steedos Platform to the ObjectStack packages means your `*.object.yml` and `*.page.yml` files have to be read by a different runtime. The README does not document a migration path, a compatibility guarantee or a rollback procedure, and the repository contains several spec-related documents (`SPEC_INDEX.md`, `STEEDOS_SPEC_REFERENCE.md`, `SPEC_VALIDATION_SUMMARY.md`) plus a `validate:package` script that runs `steedos-validate`. That validation tooling is the closest thing to a compatibility check the repository shows, and it is worth running against your metadata before an upgrade rather than after.

Third, licensing. The README badge says MIT and the repository says AGPL-3.0. If you redistribute the software, or offer it to users over a network, the difference between those two licences is the difference between permissive and copyleft. Read `LICENSE.txt` from the tag you deploy and get legal advice for your distribution model; the badges in the README are not a substitute.

Editorial conclusion

Adopt Steedos Platform if you need a self-hosted, metadata-first runtime and you are comfortable that the README points future development at the separate ObjectStack packages rather than this monorepo. Do not adopt it if you need a stable long-term API surface with no migration story, or if AGPL-3.0 does not fit how you distribute software. Before committing, verify two things: which branch and tag you are actually deploying, and whether the ObjectQL metadata files you write today will still be read by the ObjectStack packages you plan to move to.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. steedos/steedos-platform on GitHub