> ## Documentation Index > Fetch the complete documentation index at: https://datagen.dev/llms.txt > Use this file to discover all available pages before exploring further. # 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 **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](/apps/build#how-the-app-starts)). In **Save new version**, optionally describe what changed under **Version notes**, then click **Save version**. 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`. ### 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//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](/foundation/vault). ## The app detail page `/signalgen/apps/` 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. 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. **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. 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. Click **Save automation**, then **Run now** to try it immediately. The automation runs as the member who created it, so their credentials are used. **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 Build, publish and share a marimo dashboard on the demo data. Build agents that open, call and create apps. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.