Skip to main content
cpsl.App is the root object for a Capsule application. The shortest useful way to think about it is this: App is both the place where you describe the product and the object Capsule reads when it serves or deploys that product. Pages, collections, integrations, and deploy knobs all live on the same object for that reason.

Worked example

This is the kind of App definition a real product grows into:
You do not need everything at once, but this example shows why App is the center of Capsule. Runtime, pages, state, integrations, tasks, channels, and pricing all hang off the same object.

Constructor

You do not need all of these fields on every app. A small app often starts as just:

Constructor arguments

App-building methods

Most of the App API is declarative. You call these while the module is imported, and Capsule remembers the resulting configuration. The main question is usually not “how do I call this?” but “which part of the app should own this concern?”

app.collection(...)

Declare a persistent collection and get back a CollectionRef you can use from handlers.
This is usually the first thing to reach for when the app needs real persistent records.

app.setting(...)

Declare a scoped setting that can be bound to UI widgets or read from Python.
Settings are better for configuration than for records. Think “user preference”, not “business object”.

app.theme(...)

Configure colors, fonts, tagline, logo, and preset.
In practice, most apps call this once near the top of the file and rarely touch it again.

app.add_integration(...)

Declare a user-facing integration.
If the integration belongs to the end user, declare it here. If the credential belongs to the app itself, that is usually a workspace secret instead.

app.add_page(...)

Register a React/TSX page.
Use this when the page needs richer interaction or external frontend libraries.

app.page(...)

Decorator for Python DSL pages. The function must return cpsl.ui.Page.
Use this when the page is mostly a composition of metrics, tables, charts, and settings controls.

app.workflow(...)

Register a named workflow surface.
Use workflows when users should start a named flow from the sidebar and continue inside a session-backed chat. See Workflows for launcher UI, start handlers, actions, and message handlers.

app.data(...)

Register a named JSON data source.
This is the cleanest way to expose computed data to both DSL pages and React pages.

Functional-only methods

These are only valid when the app was created with image=... on the constructor:
  • app.boot()
  • app.shutdown()
  • app.enter()
  • app.exit()
  • app.message()
  • app.schedule(cron)
  • app.endpoint(...)
  • app.asgi(...)
  • app.task(...)
Here is a small functional app that uses several of them together:

Class-based apps

For class-based apps, use @app.cls(...) and the global decorators from cpsl:

@app.cls(...) arguments

app.settings

Every App has a settings accessor:
  • await app.settings.get(key)
  • await app.settings.set(key, value)
  • await app.settings.get_all(keys=None)
Example:

See also