Steedos Platform: metadata-driven enterprise apps on the way to ObjectStack

What Steedos Platform solves, and for whom

Steedos Platform targets the gap between writing an enterprise application from scratch and dragging one together in a proprietary low-code tool. Its README frames the product as an enterprise-grade implementation of an architecture it calls ObjectStack, and describes the approach as metadata driven, in the same family of ideas as Salesforce. The stated goal is that data models, logic and interfaces are declared as metadata rather than hand-written boilerplate.

The audience is narrower than the tagline suggests. This is for teams that already accept a platform runtime between their business logic and their database, and that want to keep that runtime self-hosted. The repository is a Yarn workspace monorepo with packages, services, ee and builder6 as workspace roots, which tells you it is aimed at developers who will read the source when the documentation runs out. Someone who wants a finished CRM will not find one here; someone who wants a substrate for building one will recognize the shape.

ObjectQL, ObjectOS and Object UI: the three moving parts

The README splits the architecture into three named pieces. ObjectQL is described as the protocol, a unified language for defining data, logic and UI, and the standard interface between AI and the software. ObjectOS is the engine, a headless runtime kernel that the README says provides standardized APIs, authentication, permissions and workflow automation. Object UI is the renderer, a schema-driven engine based on React and Tailwind that turns metadata into interfaces.

Concretely, the README says AI generates *.object.yml files for data models and *.page.yml files for pages, and that ObjectOS then exposes GraphQL and REST APIs for every model. The README also claims the same metadata can be deployed to MongoDB, PostgreSQL or plain JSON files. That last point is the most interesting design decision in the whole document, because it means the data layer is meant to be swappable underneath a stable metadata contract. Whether that holds across every feature is not something the README demonstrates; it states the capability without a compatibility matrix.

The repository layout supports the story. The README names @objectql/spec for type definitions and JSON schemas, objectql for the server-side ORM and runtime, @object-ui/react for frontend rendering, and @objectapp/* for modular business application packages. The top-level directories also include a builder6 workspace and a services directory, and the root package.json wires a moleculer-runner repl command through steedos.config.js, which is consistent with the microservices framing in the README.

Installing Steedos Platform and starting a first app

The README gives two installation paths. The fastest is a Docker image, which it describes as the latest stable version of Steedos before the ObjectStack transition is complete. The command maps container port 80 to host port 80, so the instance is reachable at localhost once the container is running.

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

The second path scaffolds a new application. The README's example names the project my-app, changes into it, then installs dependencies and starts the dev server with yarn. It says to visit http://localhost:5100 afterwards.

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

If you are working on the platform itself rather than an app, the root package.json defines a different entry point: yarn start changes into builder6/server and runs its start script, and yarn webapp changes into builder6/webapp and runs its dev script. The root also exposes yarn docker and yarn docker:db, the latter bringing up mongodb, mongodb-init, redis and nats through docker-compose. Note the engine requirement in that same file: Node 22 or newer, with Yarn 3.8.7 pinned through packageManager. That is an unusually recent floor, and it will rule out older build images.

The migration to ObjectStack is the real constraint

The most important line in the README is not a feature. It is the block headed "We are migrating to ObjectStack," which states that the core is being refactored into a modular, headless stack, and that while Steedos Platform v2.x remains supported, future development is focused on the ObjectStack ecosystem. The release list reflects that split: the v2.7.x line continued into early 2026, while the 3.0 line appears with a stable 3.0.10 release and a 3.0.11 beta.

For an adopter this creates a fork in the road that the README does not resolve. If you build on the v2.x packages, you are building on a line the README says is supported but no longer the focus. If you build on the ObjectStack packages, you are building on a stack whose own specification is still being assembled, and whose package names (@objectql/spec, @object-ui/react, @objectapp/*) are described in the README as the target layout rather than as a finished product.

There is a second, quieter limitation. The README's capability table contrasts ObjectStack with legacy low-code and with Salesforce, but it does not document upgrade paths, deprecation windows or rollback. The repository does carry a SPEC_INDEX.md and a SPEC_VALIDATION_SUMMARY.md at the top level, which suggests the specification is being written down deliberately, but the README itself does not tell you how a v2.x application moves to v3. Treat that as an open question to raise in the project's discussions before you commit a migration budget.

How it compares with Budibase and Appsmith

The repository topics list Budibase, Appsmith and Airtable alongside Steedos, so the comparison is fair game. The difference is where the abstraction sits. Budibase and Appsmith are primarily internal-tool builders: you assemble screens and wire them to data sources, and the artifact is the app you built. Steedos Platform positions the metadata itself as the artifact, with ObjectQL as the protocol and Object UI as a renderer that consumes *.page.yml files.

That distinction matters when AI generation enters the picture. If the unit of work is a screen, generated output is a screen you still maintain by hand. If the unit of work is a schema, generated output is something a runtime can re-render, which is what the README means by schema-driven rendering and by injecting React components into a standard page layout. The trade-off is that you inherit a runtime's opinions about data modeling, permissions and workflow, and you need that runtime to be healthy. A tool builder that stores its own app definition has the same dependency in a different place.

The licence difference is worth checking too. Steedos Platform is AGPL-3.0, which is a copyleft licence with network-use terms, while several internal-tool builders ship under permissive licences. The README's badge points at an MIT licence file, but the repository is recorded as AGPL-3.0, so read LICENSE.txt rather than the badge.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-14, so the codebase is being touched. The release history is more mixed. The v2.7 line reached v2.7.32 in early February 2026, and the 3.0 line shows 3.0.10 as a stable release in late December 2025 followed by 3.0.11-beta.4 in early January 2026. Since then the visible release list shows no further tagged versions, even though pushes continued. That pattern is consistent with the README's statement that development effort has moved toward the ObjectStack ecosystem, and it means you should not expect the v2.x packages to receive new features.

The upgrade cost follows from the monorepo structure. The root package.json uses Lerna 9 for publishing and building, with yarn build running lerna run build across packages, services, ee and builder6. There are separate release scripts for a beta dist-tag and for publishing from an existing package set. If you consume the published packages rather than vendoring the monorepo, your upgrade path is a package version bump, but you are exposed to whatever the ObjectStack refactor does to those package boundaries. If you vendor the monorepo, you inherit Lerna, Yarn 3.8.7 and Node 22 as build requirements.

On licensing, AGPL-3.0 is the identifier recorded for this repository, and the README's badge claiming MIT is a discrepancy you should resolve by reading LICENSE.txt. AGPL-3.0 carries obligations when you let users interact with a modified version over a network, which is exactly the deployment shape this project targets. That is a statement about the licence text, not legal advice; if you plan to offer a modified Steedos instance to third parties, have someone qualified read the licence against your distribution model.

Editorial conclusion

Adopt Steedos Platform if you want a self-hostable, metadata-first application platform and you can live with a documented migration toward ObjectStack. Do not adopt it if you need a frozen API surface or a single stable release line. Before committing, read LICENSE.txt against your own distribution plan, confirm whether your work belongs in the v2.x packages or the ObjectStack packages, and check that Node 22 or newer and Yarn 3.8.7 are acceptable in your build environment.

Frequently asked questions

Official sources

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