Skip to content

What you get

Kumiko provides the common building blocks for a business app. Declare your features, then mount the built-in capabilities you need. They are included in the framework.

Declare a feature, get the whole stack. One defineFeature() with an entity gives you a Postgres table, typed API, validation, access rules, search, and an admin UI with list, create, edit, and filter screens.

Kumiko-generated list screen: sortable columns, filter dropdowns, and status badges
Kumiko-generated edit form: typed fields, validation, and select options
  • Schema is the source of truth, change a field, and the table, API, forms, and labels follow. → Concepts: Schemas
  • Realtime is the default, changes stream to every open browser over SSE, and concurrent edits are safe (optimistic locking), not an add-on.
  • Audit comes built in, every write is an event; you get a full history and time-travel for free. → Concepts: Events
  • A reusable design system, generated screens plus a visual styleguide for primitives, widgets, forms, charts, drawers, tables, and dashboard panels.

These are pre-built features you mount in run-config.ts and configure : you don’t write them. Each links to its reference page.

  • Users, tenants, sessions, multi-tenant accounts, tenant switching, and session lifecycle. → user, sessions
  • Email + password auth, login, signup, password reset, email verification, and invites, all the screens included. → auth-email-password
  • Feature toggles & plan tiers, gate features per tenant, enforce plan limits and usage caps. → feature-toggles, tier-engine
  • Notifications, one ctx.notify(...) call delivers over email, push, and in-app, with templates, preferences, and a delivery log. → delivery
  • File storage, upload and serve files via S3 or local storage behind one API, with signed URLs. → files

Every mail and PDF comes from a template in the database. Admins change the text, logo, layout and attachments in the browser, check the result with sample values, send themselves a test mail and publish, all without a deploy. By default platform admins edit the templates; an app can unlock single templates for tenant admins, who then adapt them for their organization.

Mail template editor with the placeholder list, the mail body and its properties
  • Placeholders the feature declares, each with a type, label and sample value. A missing required placeholder blocks publishing.
  • Layouts and letterheads frame every mail and PDF with the tenant’s logo, colours and footer.
  • PDF templates for invoices and certificates, with repeating table rows, page numbers and the template version stamped into every PDF. A mail can attach one, generated when it is sent.
  • Several languages per template, with a fallback for missing ones. → Guide: Design mail and PDF templates, document-designer

Every list screen can give its users a view menu, pinned columns, groups with server-side sums, a selection with bulk actions and an Excel export. Each part is one key in the screen’s table block; a list without it behaves as before.

Task list grouped by status with counts and sums per group and a total row
  • Columns, density, pinning, picked by the user in the view menu and kept for the browser session, with one Reset for everything.
  • Groups and totals computed on the server over the whole filtered list, with “Load more” per group.
  • Bulk actions that run a row action once per selected row through the same access checks and audit trail as a single click.
  • Export of the filtered list as .xlsx, without encrypted or sensitive fields. → Guide: Tables, what users can do, recipe
  • Background jobs, register a worker, get scheduled and event-triggered runs with a persisted run history and operator retry. → jobs
  • Rate limiting & audit, per-handler rate limits and an audit log for compliance reviews. → rate-limiting, audit
  • Config & secrets, per-tenant config keys and tenant-scoped encrypted secrets. → config, secrets

Your feature definitions already describe the app, entities, handlers, screens, labels. agent-tools turns that registry into a tool catalog an LLM can call, so a chat layer can search, open and change records instead of only talking about them. Exposure is fail-closed: a handler without a description stays invisible to the model, and a write is proposed for approval rather than executed.

The assistant layer open next to the app, with an approval card for a proposed write

The capabilities above are easiest to grasp by running a real app:

  • Marketing demo, an asset tracker and a helpdesk on one instance: the generated CRUD UI in full.
  • ShowPony tutorial, build a guest-list app step by step.
  • UI walkthrough, auth, tenant switching, language and theme toggles.
  • Styleguide, the design-guild catalog for choosing and composing the UI building blocks.
  • publicstatus.eu, a full statuspage product built end to end on Kumiko, in production.

→ Ready to build your own? Quickstart, the starter includes a demo tasks UI out of the box. · Tutorial