Carbon: an open core ERP, MES and QMS that expects you to write your own apps

Three systems sharing one schema, not three products

Carbon presents itself as the open core for manufacturing, covering ERP, MES and QMS, with the line API-first, extensible, yours underneath. The homepage is carbon.ms and the documentation sits at docs.carbon.ms.

The feature table is where the actual scope becomes clear, and it is worth reading row by row rather than as marketing. ERP covers sales, purchasing, inventory, items and accounting. MES is shop floor execution and job operations. QMS is inspections, non-conformances and CAPAs, which is corrective and preventive action in the vocabulary quality teams actually use. Then there is MRP for material requirements planning, full lot and serial traceability, multi-level bills of material, a product configurator, capacity planning against real resource capacity, custom fields on any record, an API with webhooks, an MCP client and server, and accounting described as GL, journals and third-party sync.

What is missing from that list matters as much. There is no purchasing approval workflow, no payroll, no general ledger beyond the GL and journals mentioned, and no multi-site or multi-entity accounting. The scope is a manufacturing operations core, not a full business suite.

The README explains why the project exists, and the reasoning is worth taking at face value: the authors built end-to-end manufacturing systems with off-the-shelf tools and concluded that modern API-first tooling did not exist, that vendor lock-in bordered on extortion, and that there is no perfect ERP because each company is unique. The third point is the design driver. If every company is different, the product has to be a platform rather than a finished configuration.

The permission story: RLS, ABAC and role types

The technical highlights list gives the mechanism behind the access model: unified auth and permissions across apps, full-stack type safety from database to UI, realtime database subscriptions, attribute-based access control, role-based access control with Customer, Supplier and Employee roles, row-level security, and composable user groups.

Row-level security is the load-bearing piece, and it comes from the data layer. The tech stack table names Supabase as both the database, Postgres plus RLS, and the auth provider. Realtime subscriptions then mean a shop floor terminal and a supervisor's screen see the same job state change without either polling.

Attribute-based access control alongside roles is the interesting half. Roles handle who you are, attributes handle what the row is, which is the difference between a supplier seeing only their own purchase orders and a planner seeing everything but only for the plants they are assigned to. Composable user groups are how you avoid a role explosion once you have both.

One consequence deserves flagging. If permissions live in Postgres policies, then the permission logic is in the database, not in the TypeScript, and anyone generating their own apps against the API inherits that model rather than reimplementing it. That is a genuine advantage over a suite whose authorization lives in application code you cannot reach.

A Turborepo monorepo with two top level folders

The repository follows what the README calls the Turborepo convention of grouping packages into two folders:

carbon
├── apps         # applications
└── packages     # shared code

The apps table names five of them. `erp` and `mes` are the first-class pair, both launched through the same dev command, with the CLI booting the stack and the picker selecting which one you want. `academy` is training, `starter` is an example app built on the API, and `assembler` is a geometry service written in Rust that converts STEP to GLB and plans assembly motion.

That `starter` entry is the one to look at first if you are evaluating Carbon as a platform rather than a product. It is an example application built on the public API, which means it is the shortest path to understanding what building your own screens on Carbon looks like. The `academy` app suggests the same intent for training users.

The rest of the tree explains the operational shape: `packages/` holds shared code, `crates/` holds Rust crates, `ci/` holds deployment and migration jobs, `docker/` holds compose assets, `scripts/` holds project checks such as `check-manifest` and `check-workflow-catalog`, and `patches/` exists for patched dependencies. There is also an `AGENTS.md`, a `CLAUDE.md`, a `BACKWARD_COMPATIBILITY.md` and an `.ai/` directory, which tells you the project has thought about agent-assisted development and API stability as first class concerns. `sst.config.ts` and `sst-env.d.ts` point at SST for deployment alongside the Vercel hosting listed in the stack table.

crbn up is the local development entry point

Every app runs through the same command, which delegates to a per-worktree dev CLI called `crbn up`:

pnpm dev
pnpm dev:academy
pnpm dev:starter
+

The README describes what that command does: the CLI boots the Docker stack, applies migrations, regenerates types and swagger, and then a picker decides which app you get. Two consequences follow. First, migrations are part of starting a dev environment, so the database is never out of step with the code. Second, regenerating types and swagger on boot means the TypeScript types and the OpenAPI document are derived artefacts rather than files someone has to remember to update.

The regeneration step is what makes the full-stack type safety claim credible. Types generated from the database schema and from the API description cannot drift from either, which is a stronger guarantee than hand-maintained interfaces.

The migration commands are visible in `package.json`. `db:migrate` runs `crbn migrate`, `db:migrate:new` delegates to the `@carbon/database` package, `db:seed` runs the seed task through Turbo, and there are check commands for backups and datasets that are scoped to the jobs and database packages respectively. The CI equivalents, `ci:deploy` and `ci:migrations`, delegate to a dedicated `ci` workspace package. `db:function:new` suggests database functions are created through a generator rather than by hand.

A Rust geometry service sits inside a TypeScript monorepo

The `assembler` app is the odd one out and the most interesting. The stack table attributes geometry to Rust, specifically FCL collision and OpenCASCADE CAD, and the apps table describes the service as STEP to GLB plus assembly motion planning. `crbn up` spawns it, though the README notes it needs a release binary.

The `Cargo.toml` confirms the scope. The workspace members are `crates/*` and `apps/assembler`, edition 2021, and the dependencies are `gltf` for glTF loading, `meshopt` for mesh compression, `bytemuck`, `nalgebra` for linear algebra, `serde` and `serde_json`, and `sha1`. That is a geometry and mesh pipeline library set, not a general purpose Rust codebase.

There is a `profile.profiling` section worth noting because it is the kind of detail that indicates real performance work. It inherits the release profile, keeps debug info and frame pointers so native stacks symbolicate, and the comment names samply as the profiler. Building it uses `cargo build --profile profiling`.

Why put this in Rust at all? STEP and CAD geometry work is numerically heavy and awkward in JavaScript, and the wasm-free path means the geometry service runs as its own process spawned by the dev CLI rather than shipping a wasm blob to the browser. The cost is a second toolchain, a second build step and a release binary to manage, which the README flags rather than hides.

Three different licence signals, and one of them is unresolved

Carbon's licence reporting is genuinely inconsistent across sources, and anyone considering it for commercial use needs to resolve that before reading anything else.

The README badge says AGPL-3.0. The `Cargo.toml` declares `license = "MIT"` for the Rust workspace package. The repository metadata reports NOASSERTION, which is GitHub's way of saying no licence was detected from the files it looked at. Two of those three can be reconciled, since a repository can carry an AGPL application with MIT licensed Rust crates, but the mismatch between the README badge and the Cargo workspace declaration is not something to guess about.

This is not legal advice and the repository does not settle it. What the tree does suggest is that the project treats API compatibility as a commitment: `BACKWARD_COMPATIBILITY.md` exists at the top level, which is the document to read if your own apps depend on the API staying stable across upgrades. That matters more than the badge for anyone building on top.

The rest of the operational signals are consistent. The stack is TypeScript, React, Supabase and Rust with Biome for linting, husky and lint-staged for hooks, Turbo for task orchestration, pnpm workspaces with a `pnpm-workspace.yaml` and a `pnpm-lock.yaml`, Lingui for translations with a `lingui.config.js`, and Vite for the build. `package.json` is marked private, so the monorepo root is not itself a published package. The last push was on 2026-09-24 and the repository has no GitHub releases, so the version history lives in the commits.

Configuration comes from .env, with local values generated for you

The `.env.example` file is unusually well commented, and it documents the intended configuration model better than most manuals do. You copy it to `.env` and fill in genuine secrets. Ports, URLs, Supabase keys, Redis and Inngest values are auto-generated into `.env.local` by `crbn up`, and Vite and React Router load `.env.local` on top of `.env`. The comment explicitly tells you to leave port, URL and Supabase variables out of the file you edit.

The variables that remain are the ones with an opinion attached. `AUTH_PROVIDERS` takes `email`, `google`, `azure` or `passkey`. `CARBON_EDITION` takes `community`, `cloud` or `enterprise`, which is the clearest signal in the repository that this is an open core product with a paid tier. `SESSION_SECRET` and `RATE_LIMIT` are set directly. `LOG_LEVEL` is commented out with its six levels and a note that the default differs by environment.

Beyond that, the file covers Supabase OAuth client IDs and secrets for Google and Azure, PostHog keys, Stripe keys including a Connect webhook secret for payments fan-out, a GTM secret for notifications, and SMTP settings with the two usual ports, 465 for implicit TLS and 587 for STARTTLS. Resend appears as a marketing-only transport and also as a legacy fallback when the SMTP variables are unset.

The presence of Stripe and PostHog keys in an example file is worth naming plainly. Carbon is a product with billing attached, not a hobby project you deploy and forget.

Editorial conclusion

Carbon is worth evaluating if your manufacturing operation runs on Postgres and you would rather build the specific screens you need on an API than configure a generic suite, because the README is explicit that the API is the intended extension point and a starter app exists to copy. It is the wrong choice if you need a system you can install and use next week without engineering time, since the stack spans React Router, Supabase, Redis, Inngest, Stripe and a Rust geometry service. Before anything else, settle the licence question, because the README badge says AGPL-3.0 while the Rust workspace in `Cargo.toml` declares MIT, then clone the repo and run `pnpm dev` to see the `crbn up` picker on your own data before reading any documentation.

Frequently asked questions

Official sources

1. crbnos/carbon on GitHub
2. Issues
3. Project website
4. README