Backend
Your app's backend is a set of compositions: layers of existing catalog workflows with every input wired from input, step or static. Saved, a composition is a normal workflow type, virtual.<composition_uuid>@<version>.
There is no backend repository to deploy for this. Orkestia's rule is reuse first: reuse a live workflow, then compose, then add a generic workflow to the library that already owns that provider.
The parts
| Part | What it does | Detail |
|---|---|---|
| Composition | Your logic as structure, run by the engine with org scoping, history and retry | Compositions, Virtual workflows |
| Exposure | Which composition versions a signed-in end-user may start (identity.app.expose-virtual-workflow) | End-user data |
| Data | Rows the composition reads and writes, scoped from the token | App Data |
| Schedules | Run a workflow on a timer or a cron time with a timezone (schedule.create, pause, resume, update, delete) | Keep scheduled compositions cheap |
| Triggers | Start a composition when rows of an App Data table are inserted or updated (trigger.create), instead of polling | Keep scheduled compositions cheap |
| Approvals | Put a human decision in the middle of a run (approval.request.*) | Governance and approvals |
| Processes | When you need real code, launch a container on App Host | Website and process |
What the platform guarantees
- An end-user token can start only exposed virtual workflows, never raw catalog types.
- The end-user principal is injected from the verified token. A caller cannot set or override it.
- Every run has append-only history and can be retried, and is visible in Lumen.
When a composition is not enough
Use a process on App Host for long-lived listeners or code that cannot be expressed as catalog steps. It still reaches App Data through a database attachment, not a pasted connection string.
Build apps
The path for building an app on Orkestia — sign-in, backend, data, hosting, chat, domain, modules and flags, environments, pricing — in the order you meet them.
Modules and feature flags
Three separate controls decide whether a signed-in user can use a part of your app — exposure, capability and feature flag — and how each one fails.