Jetstack is a configurable platform for building business applications inside a tenant. Instead of hardcoding a complete application for each use case, you define a reusable model and let the platform assemble the runtime behavior from that definition.
In practice, Jetstack combines:
Jetstack is not only:
Those things may appear inside the platform, but the platform itself is broader. It is closer to an implementation framework where model, UI, logic, access, and operations stay connected.
Jetstack becomes valuable when a tenant needs:
A typical implementation follows this loop:
That loop is repeated throughout the product.
Jetstack's runtime is shaped by a small set of repeated concepts:
This matters because many fields in Jetstack do not behave as static text. They are evaluated through expressions, scope resolution, permission logic, or filter translation at runtime.
This is where types and properties live. It defines the structure of the tenant and the meaning of stored values.
This is where queries, filters, grouping, calculations, tags, and folder context live. It defines what data a user or integration is working with.
This is where views, modules, canvases, forms, and actions live. It defines how users experience the model.
This is where automations, scheduler tasks, and event-driven behavior live. It defines what happens when work is performed or when time passes.
This is where roles, permissions, groups, versions, sync, translations, customization, and app settings live. It defines who can do what and how the tenant is operated.
This is where REST, MCP, webhooks, AI agents, sidecar services, and advanced tools live. It defines how Jetstack participates in a larger system landscape.
The codebase exposes the platform surface mainly through:
app/model/ActiveResource/ResourceTypesPropertyTypesapp/Presentersapp/model/libsapp/apiai-sidecarYou do not need to read those files to use the platform, but this documentation uses them as the source of truth for platform behavior.
A procurement tenant might contain:
Supplier, Contract, Request, and Invoice typesEach of those pieces is configured separately, but they work because they share the same underlying platform model.
After this chapter, the most important next concepts are: