Apps are workspace-level extensions. They currently group publishing, automations, MCP client setup, and published connectors in one place.
Open Apps
Go to Workspace → Apps. The page shows:
Publish — manage the workspace's public site.
Automation — create code-backed workspace automations.
Connectors — set up MCP client access and manage published workspace connectors. Admins can create and revoke connector credentials.
Automations
Automations run sandboxed JavaScript inside a workspace. They are useful for recurring cleanup, tagging, summaries, AI-assisted maintenance jobs, and one-off operational scripts.
An automation has:
a name and optional description
an enabled or draft state
a trigger type and trigger configuration
handler code
run history
Workspace members can read automations and run history. Workspace admins and editors can create, edit, delete, enable, disable, and run automations.
Trigger types
The automation data model and editor expose four trigger types:
Manual — runs when someone clicks Run now.
Schedule — runs from a cron expression and timezone when DBOS scheduling is configured.
Event — reserved for workspace event triggers such as
resource.created,resource.updated,resource.deleted, orresource.tagged.Webhook — reserved for POST-triggered automations.
Current runtime support is strongest for Manual and Schedule. Event and webhook triggers can be selected in the editor and stored on the automation, but the current codebase does not expose the event dispatcher or public webhook receiver yet. Do not document event/webhook automations as production-triggered until those routes exist.
Build with AI, then edit code directly
The automation editor has a chat panel for describing what you want. Dokki asks the model to return a complete JavaScript handler and inserts it into the visible code editor. The code remains editable, so you can review or change it before saving.
Save the automation before running it. Existing automations can be run manually from the editor, and the run history refreshes afterward.
Runtime limits
Automation code runs in a QuickJS sandbox. It cannot use the DOM, Node APIs, raw fetch, imports, require, or npm packages. The supported runtime is the ctx object:
ctx.trigger
ctx.workspace
ctx.resources.query(...)
ctx.resources.get(...)
ctx.resources.tag(...)
ctx.resources.untag(...)
ctx.doc.read(...)
ctx.ai.run(...)
ctx.log(...)
ctx.skip(...)
ctx.fail(...)ctx.ai.run bills through the normal AI usage path. Use ctx.log to make run history useful, ctx.skip when the run should stop without being treated as an error, and ctx.fail for explicit failures.
Handlers have a default 30-second runtime cap, a 64 MB QuickJS memory limit, a 1 MB stack limit, and a 500-entry run-log cap.
Schedule behavior
Schedule triggers use DBOS. If DBOS_SYSTEM_DATABASE_URL is not configured, schedule registration is disabled and scheduled automations will not fire. Updating an automation rewires its DBOS schedule by deleting the old schedule and creating the new one if the automation is enabled, uses trigger_type='schedule', and has a cron expression.
Scheduled runs skip automatically when their workspace is archived. Manual runs remain available for deliberate testing and debugging.
Run history and operations
Each run records status, duration, logs, trigger payload, error message, and timestamps. Runs can finish as success, error, skipped, or timeout.
Connector relationship
Connectors and automations solve different problems. Use automations when Dokki itself should run sandboxed workspace code. Use connectors when an external MCP client, agent, or tool needs stable access to workspace resources.