See it before you install it

lumen.supero.live is one of the 19, running the code in apps/healthcare/lumen. The login page lists every demo account with its role and password — click one and you are in. No signup, nothing to install.

Sign in as the front-desk user, then sign out and back in as the patient. The patient's record is missing clinical_notes — and nothing in ui/app.js is doing that. The rule is five lines in apps/healthcare/lumen/setup.py.

Or check it from a terminal in ten seconds, no signup, no clone of your own domain:

git clone https://github.com/supero-platform/supero-apps
cd supero-apps/verify && ./02-rbac-enforcement.sh

That script logs into the live insurance demo as a claims adjuster and as a policyholder, finds one claim both can see, and compares the two responses. The adjuster gets fraud_score and internal_notes; the policyholder gets the same record without them. verify/ explains what it proves — and what it does not.

Then run it yourself, in about two minutes

New here? Start with lumen — it is the smallest app in the repo and the one the docs follow.

git clone https://github.com/supero-platform/supero-apps
cd supero-apps/apps/healthcare/lumen

cp .env.example .env    # set SUPERO_DOMAIN, SUPERO_ADMIN_EMAIL and SUPERO_PASSWORD
./run.sh

run.sh creates a venv, installs the supero SDK, registers your domain, uploads the schemas, seeds demo data, wires up roles — then serves the app at http://localhost:5663.

That takes about 90 seconds on a cold machine with an empty pip cache — roughly 10 seconds of install and 60-odd of platform setup. Call it two minutes with the time it takes you to fill in .env.

You do not need an account, an invite, or a credit card. Domain registration is open. The name you put in SUPERO_DOMAIN becomes yours if it's free.

Prefer containers? docker compose up works identically.

The apps

Each one is a complete, multi-tenant application — public storefront and admin panel, with role-based access enforced on the server, not in the UI.

🩺 Healthcare & Life Sciences

💰 Finance & Insurance

🛍️ Commerce & Sales

🔐 Multi-tenant (one deployment, many organisations)

Every app above runs a single organisation. These four run several at once, and the isolation is enforced by the server: a user signed into one tenant cannot read another tenant's rows even by calling the API directly with their own valid token. Two of them also demonstrate field-level access control on top of that, so a row you can read still arrives with fields removed.

Sign in on any of them and the login page lists every demo account with its tenant, role and password — click a row to fill the form.

🏢 Operations & Services

🏡 Property & Media

Build it with your AI

Every app ships a CLAUDE.md (and .cursorrules / .windsurfrules) so your assistant understands the codebase before it touches a line.

You can also connect your editor directly to the platform over MCP — 64 tools that let an assistant design schemas, run CRUD, connect a database, and take an app from a sentence to a live URL:

claude mcp add --transport http supero https://api.supero.dev/mcp/v1/messages \
  --header "X-API-Key: ak_your_key_here"

Then just ask:

"Add a waitlist to the clinic app — patients join, staff promote them when a slot opens."

The interesting part is what the assistant is allowed to do. An MCP call carries your credential to the same API a browser would use — no service account, no elevated path. So the agent inherits your permissions rather than getting its own, and the row scoping and field hiding above apply to it identically. An agent you point at a customer's data is bounded by the same policy the customer is.

The server is live and you can inspect it without a key:

curl https://api.supero.dev/mcp/v1/info

docs/mcp.md covers getting a key and the tool families. The complete reference, every parameter, is at docs.supero.dev/developers/mcp/tool-reference.

What you actually get

Two things, and it's worth being precise about which is which.

From schemas.py (95–270 lines, median 120), automatically — no code:

ui/app.js is the one part that's real code you own. It's the app's custom storefront — 400 to 1,100 lines of React depending on the app, median around 800 — generated as a working starting point, then yours to edit however you like. So you get the tedious 80% (APIs, auth, admin, RBAC) for free, and a real front-end you control — not a locked template.

Access control is declared in setup.py, and the server applies it — not the UI. You write row scoping (filter_field="owner_username") and field hiding (hidden_fields=["clinical_notes", "diagnosis"]). A patient calling the API directly with their own valid token — curl, browser closed, front-end out of the picture:

GET /api/v1/crud/<your-domain>/appointment

gets their appointments back with clinical_notes absent from the response body. Nothing in ui/app.js is doing that — delete the entire front-end and the field still does not come back. That's why lumen keeps clinical notes provider-only and sentinel hides fraud scores from claimants without either app writing a line of access-control logic.

Two things worth being precise about, because they decide whether you can rely on this:

• It covers the entities you declare in your own schemas. Platform-managed types — accounts, API keys, domains, projects, tenants — are governed by role permissions instead. That is a different mechanism, and hidden_fields does not extend to them.
• It is a server-side response filter, not a database-level projection. The field is removed before the response is written, not withheld from the query.

Open their setup.py — the policy block is short, and it's the thing worth checking first. Then check it against your own deployment rather than taking this page's word for it.

Zero build. React and Tailwind load from CDN. No node_modules, no bundler, no npm install. Edit ui/app.js, refresh the page.

Each app carries five suites. Three are static validators that check the bundle's own consistency and need nothing running. Two — crud_tests.py and e2e_tests.py — make real HTTP calls against your domain, and are the ones that assert the access-control claims. The live pair skip with a stated reason when no app is serving, so a fresh clone stays clean:

cd apps/healthcare/lumen && ./tests/run_tests.sh

How this works, honestly

This is open-core, and we'd rather say so plainly than have you find out.

• The app source in this repo is MIT — genuinely yours. Fork it, sell it, rip the UI out.
• The supero SDK is MIT and open on PyPI.
• The platform these apps call (api.supero.dev) is a hosted service. Schema resolution, the multi-tenant runtime, RBAC enforcement, and orchestration run there. That part is not open source.

So an app here is a thin, portable client that calls the platform for schema resolution, RBAC, and orchestration. That's the trade: you skip building and operating a backend, and in return the backend is a managed service.

Your data and your exit. The domain, schema, and data are yours. Every record is reachable through the same REST API the app uses, so export is a loop over GET /api/v1/crud/{domain}/{type} with your API key — nothing is trapped in a proprietary store you can't read. And for teams that need to run inside their own network, self-managed / on-prem deployment is available under an enterprise agreement (hello@supero.dev) — so "what if the vendor goes away" has a real answer. See deploy.md.

Regulated data — read this first. These are reference applications, not certified compliant systems. lumen and trialcore show the shape of healthcare access control; they are not HIPAA-certified and ship with no BAA. Before putting real PHI, PII, or regulated financial data into anything here, talk to us about compliance posture, data residency, and a BAA — don't assume the demo covers it. See SECURITY.md.

Pricing. There's a free tier — enough to run everything in this repo — then usage-based beyond it. We don't publish the numbers yet. They're visible in the dashboard once you have a domain, which costs nothing to create, and you can ask us before you get that far. We'd rather say that plainly than link you to a page that isn't there.

Anatomy of an app

apps/healthcare/lumen/
├── README.md            ← how to run this specific app
├── CLAUDE.md            ← context for AI assistants (also .cursorrules/.windsurfrules)
├── CUSTOMIZATION.md     ← branding, layout, services, admin panel
│
├── schemas.py           ← your data model            ~120 lines
├── setup.py             ← seed data, roles, policies
├── config.py            ← app name, services, tenants
├── .env.example         ← copy to .env, set your domain
│
├── run.sh               ← bootstrap + serve
├── Dockerfile           ← container image
├── docker-compose.yml   ← docker compose up
│
├── tests/               ← crud / integration / e2e
└── ui/
    └── app.js           ← your screens (the only UI file you edit)

Everything else in ui/ — the component library, schema bindings, dev server — is restored from the supero wheel on every run.sh. That's why it isn't committed here: it's a build artifact, not source.

Docs

FAQ

Do I need a Supero account? No. ./run.sh registers the domain you name in .env. No signup wall.

Is my data locked in? No. It's your schema and your domain. Apps run on your machine, your cloud, or a managed URL.

What's the catch on the free tier? Usage limits. The current numbers aren't published — they're in the dashboard once you have a domain (free to create, no card), or ask us.

Can I use these commercially? Yes — the app source here is MIT. Build on it, sell it, fork it.

Where's the platform source? The supero SDK is MIT and open. The hosted platform (generation, multi-tenant runtime, orchestration) is a managed service.

Contributing

Issues and PRs welcome — app improvements, new verticals, doc fixes. See CONTRIBUTING.md.

Built something with Supero? Open a PR and add it to the gallery.