Publish and Share Apps

Save and publish app versions, open the running app, control who can access it, and run the builder on a schedule

A custom app moves from the builder’s draft to your team in two steps: Save creates an immutable version, and Publish makes one version the one everyone opens. This page covers that cycle, opening and managing the running app, who can access it, and automations.

Notebooks are edited in place in the marimo editor and do not use the save and publish cycle. Opening, instances and access work the same for both kinds.

Save a version

1. Click Save in the App Builder

   Save is in the builder’s header, next to the count of unsaved changes. Apply or discard any open editor changes first, and make sure the app has a datagen.app.json (see How the app starts).

2. Add version notes

   In Save new version, optionally describe what changed under Version notes, then click Save version.

3. Wait for the image

   Saving installs the version’s dependencies into its own image. The version row in Versions shows the image state: image queued, image building, image ready or image failed. A version can be published once its image is ready.

Saving never changes what members see. The live app keeps serving its published version while you keep working on the draft.

If an image fails, expand the row to see the build output and click Retry build. When the failure comes from the install or build command itself, fix the files in the builder and save again.

Publish a version

Open Versions in the builder’s left column, or the Versions tab on the app’s detail page, and click Publish on the version you want live.

Publishing a version:

• makes its files and its start settings (command, port, working directory, environment) live together;
• rebuilds the running app. Other members’ open copies close and show the new version the next time they open the app;
• leaves your draft untouched.

The published version carries a Live badge, and the builder header shows live v<n>.

Roll back

Every save creates a version, and only the published one runs. To roll back, click Publish on an older version. Nothing is deleted; publishing simply moves which version is live.

Delete removes a saved version and its files. Version numbers are never reused, so a link to a deleted version reads as gone rather than pointing at different content.

Export and import

• Export on the detail page downloads the published version as a zip. In the builder, Export downloads the version you just saved, or the published version. An export is always a saved version, never the draft.
• Import on the detail page replaces the builder’s draft with a folder from your computer. The published app stays unchanged until you save and publish.

Open the running app

Click Open app on the detail page, or open the app from the Apps list. The running app appears at /signalgen/apps/<appId>/view, inside the workspace with the navigation still visible.

While the app starts, a progress panel shows each step: checking access and the published version, preparing the environment, loading files, connecting sources and waiting for the server to respond.

The viewer toolbar has:

• App details: back to the detail page.
• Refresh: reloads the app. It wakes an app that went to sleep and picks up a newly published version.
• Edit (custom apps, Builder or Admin): opens the App Builder.
• Files (custom apps): browses the files the running process actually has.

If the app’s Connection Vault holds a per-user credential you have not provided yet, the viewer shows Set up your credentials instead of the app. Click Set up in the vault, add your value, then come back and refresh. See Vault.

The app detail page

/signalgen/apps/<appId> describes the app without starting it. Its tabs:

Tab	What it shows
Files	The published version’s files, with previews
Versions	Saved versions; publish, delete or retry an image
Instances	Every member currently running the app
Sources	Workspace files the running app reads
Tools & knowledge	Knowledge bases and skills for the builder
Settings	Harness, vault, sandbox, secrets and start settings
Automations	Scheduled builder runs
Access	Per-app role overrides (Admins only)

Instances

Each member who opens an app runs their own copy in their own sandbox; they share the app’s files, not the process. The Instances tab lists who is running it, when they started and when they were last active.

• Stop in the header stops your instance. Files are preserved, and opening the app again relaunches it.
• Terminate on another member’s row stops their instance immediately. They can reopen it.

Who can access an app

Apps are opened by members of the workspace. What each member can do depends on their workspace role:

Action	Viewer	Operator	Builder	Admin
See and open the app, read its files and versions	Yes	Yes	Yes	Yes
Stop their own instance		Yes	Yes	Yes
Open the builder, save, publish, change settings, manage automations			Yes	Yes
Terminate another member’s instance, delete the app			Yes	Yes
Set per-app access overrides				Yes

To share an app with a teammate, invite them to the workspace and send them the app’s link. Agents in chat can also open an app beside the conversation with their open_app tool.

Per-app access overrides

When per-resource access is enabled, Admins see an Access tab on the detail page (not in personal workspaces). An override replaces a member’s workspace role on this app only.

1. Add an override

   Click Add override, choose Member or Group (an identity-provider group), and pick the effective role: Hidden, Viewer, Operator or Builder. Hidden removes the app from that member’s view entirely.

2. Set the default for everyone else

   All other members sets the role for every non-Admin member without a more specific override. Inherit workspace role keeps their normal role.

Individual overrides win over group overrides, which win over the default. Admins are never affected.

An elevated role applies to the app’s page only, never to credentials. Binding a vault, tool bundle or secrets still requires the workspace role.

Automate the builder

The Automations tab runs the App Builder on a schedule, for example “every Monday at 09:00, refresh the sources and update the dashboard”. A run uses the app’s own model, sandbox and credentials, exactly like a turn you type.

1. Create the automation

   Click New automation and fill in:

   • Name: for example Weekly refresh.
   • Prompt: sent verbatim to the builder, in a fresh conversation each time.
   • Schedule: a standard 5-field cron expression, for example 0 9 * * 1.
   • Time zone: an IANA name such as Asia/Taipei. Defaults to UTC.
   • Enabled: disabled automations never fire.
2. Save and test

   Click Save automation, then Run now to try it immediately. The automation runs as the member who created it, so their credentials are used.

3. Review and publish

   Recent runs shows each run’s status. A completed run changes the draft only; open the builder, save the result as a version and publish it.

A scheduled run never publishes. If someone has the builder open when a run is due, the run is skipped (Skipped (builder in use)) rather than queued; the next scheduled time tries again. A run is also skipped when no sandbox capacity is available (Skipped (no capacity)).

Next

Ship an app tutorial

Build, publish and share a marimo dashboard on the demo data.

Agents overview

Build agents that open, call and create apps.