Apps

An app is a custom interface for your workspace — a screen you build, running on your data, with the business logic you decide.

You author one two ways: write the code directly in Rollout, or connect a git repository. Either way it becomes an app you can open, place on a page, and share.

What an app is for

Rollout gives you tasks, entities, workflows and dashboards out of the box. An app is for the cases those do not cover: a purpose-built screen for one job, shaped the way your team works rather than the way the product ships.

Typical uses:

• a focused console over one object, with only the fields and actions that job needs
• a calculator or planner whose logic is specific to your business
• an interface for people who should not see the rest of the workspace
• a compute step a workflow calls

Two ways to build one

Write it in Rollout. Create an app, write the code in the built-in editor, and Save. The validated build becomes live immediately. Good for team interfaces over your data and tools (tables, forms, charts, review queues) and anything you want to iterate on without leaving the product.

Connect a repository. Point an app at a git repo containing a Dockerfile. Rollout builds a container image from your source and runs it. Good for anything with real dependencies, a build step, or a language runtime — a Python service, a bundled front end, an existing project.

Both produce the same kind of app. The difference is only where the source lives.

What an app can do

Read and write workspace data, through tools you grant it explicitly. An app declares which tools it wants; you review their settings and credential consent before they can run. Nothing is available by default.

Run its own backend. An app built from a repository can serve HTTP — so the interface talks to your own code, in your own language, with your own libraries.

Be placed anywhere. Open it at its own address, pin it directly to Home or the sidebar, or embed it on a Page when it belongs alongside other content.

Pin an App

Use the star beside its name to add it to your personal Favorites. To place it for a shared audience, choose Place in the running App or Place in navigation in the management menu. Select Home tab, Sidebar, or a specific sidebar section. You can change the entry's label and icon, or remove it later in the same dialog.

Home keeps Page and App tabs together, and links inside an App keep you on Home. An App needs no wrapper Page. Placement uses its existing sharing: only people who can run it see its navigation entry. Share the App from Access first if the intended audience is missing. Workspace placement requires a workspace admin; Team placement requires that Team's admin or a workspace admin.

Be shared, including with people who have no Rollout account. See Sharing an app below.

What an app is not

This matters more than the feature list, because it is what keeps apps simple and predictable.

An app has no storage of its own. Anything it needs to remember goes into Rollout — entities, records, workflow storage. An app can be stopped, restarted or moved at any moment, and nothing is lost, because there was never anything in it to lose.

An app does not run in the background. No cron, no queues, no long-running jobs. It answers requests and goes to sleep. Scheduled and long-running work is what workflows are for, and a workflow can call an app whenever it needs to.

An app is not a hosting platform. One container, one port, no volumes, no custom domain, no public address of its own. Everything reaches it through Rollout — which is also where access control, identity and rate limiting live. If you need to host a service on the open internet, host it yourself and connect to it with a workflow.

An app sleeps when unused. After a period of inactivity it stops, and the next visit starts it again. That first request after a nap takes a few seconds. In exchange, an idle app costs nothing.

Apps and workflows

They are complements, and the split is deliberate:

An app can call workflow tools you have granted it. A workflow can call an app's backend as a compute step. Neither owns the other.

If you find yourself wanting an app to run on a schedule, that is a workflow. If you find yourself wanting a workflow to render a screen, that is an app.

Creating and saving

Open Apps and choose New app. Workspace members can author source within their current App permissions. App managers configure actions, account consent and access. Deployment additionally requires the current deployment rights. Saving never lends the viewer the App's execution authority.

Native Save validates and builds before replacing live source. Undo restores one previous accepted native source/settings through current validation and permissions; it never restores revoked consent. There are no numbered App releases, Copy to Draft or persistent draft history. Workflows retain Publish.

The Calls tab shows governed calls and approval context. Decisions happen in the Inbox under the current review policy.

Writing an app in Rollout

The editor stages file edits, renames, deletes and assets until one coherent Save. A stale Save preserves local edits and asks you to reconcile against the current App before saving again.

Upload images, fonts and media with Upload asset. Reference an asset by its path (<img src="assets/logo.png"> works as written) or import it: import logo from "./assets/logo.png".

Libraries you can use

An app can import:

• React, and Rollout's app SDK (@rollout/sdk) for tools, storage and routing
• the shadcn/ui components, as @/components/ui/<name>: button, card, table, dialog, sheet, dropdown-menu, select, tabs, tooltip, popover, form, input, textarea, checkbox, switch, radio-group, slider, calendar, command, accordion, alert-dialog, avatar, badge, breadcrumb, pagination, progress, scroll-area, separator, skeleton, toggle, toggle-group, hover-card, sonner (toasts), and chart
• what those components are built on: recharts, @tanstack/react-table, react-hook-form with zod and @hookform/resolvers/zod, date-fns, react-day-picker, lucide-react, cmdk, sonner, and the Radix primitives

That set is fixed and curated by Rollout. Each app includes only what it imports. Need another library? Ask, and it can be added. If you need arbitrary packages or a build step of your own, connect a repository instead.

Pages inside an app

An app can have its own pages. useRoute() from @rollout/sdk gives the current path and a navigate function. When the app is open at its own address, the path shows in the browser's address bar: back and forward work and you can link to a page inside the app (/apps/<app>/-/orders/42).

Sharing an app

An app can be shared beyond your workspace, and this is where Rollout does something a little unusual.

A shared app runs under an agent's identity, not yours. An agent is a member of your workspace like anyone else — you add it to teams, and you share data with those teams. Whatever the agent can see, the app can see. Nothing more.

That means:

• you decide exactly what a shared app can reach, using the same teams and sharing you already use
• everyone viewing it sees the same thing, because it is the agent's access, not the viewer's
• the viewer needs no Rollout account at all

A shared app gets its own link. You can revoke it at any time, or set it to expire. Revoking is immediate and permanent for that link.

An app that reads or writes your data can only be shared with an agent named. That is the whole point of the model: you decide whose authority the link acts under, explicitly, before it exists. An app that only presents and computes can be shared without one.

Changing your mind means revoking the link and creating a new one — a link's identity includes the agent it acts as, so it cannot be quietly repointed at an agent with wider access.

Archiving an agent immediately stops every link that acted as it.

A shared app can still call its own backend. That backend is your code talking to itself — it carries none of your workspace's authority, and Rollout rate limits it per viewer.

Limits

• Apps written in Rollout: up to 2,000 files; text files up to 1 MiB each and 16 MiB in total; assets up to 8 MiB each and 64 MiB in total (500 assets).
• Builds: live and one previous accepted build are retained.
• Repository apps: your repository needs a Dockerfile; the image is built by Rollout and stored privately. Build time is metered against your workspace.
• Backends: one HTTP port, declared with a health check path. No volumes.
• Idle: an app stops after a period of inactivity and cold-starts on the next request.
• Concurrency: a workspace has a ceiling on how many app backends it can hold warm at once.
• Requests: backend calls are rate limited per viewer.

Getting started

1. Go to Apps and choose New app.
2. Choose Write code or Connect a repository.
3. Grant any tools it needs, and review them.
4. Save native source, or Deploy Git source.
5. Open it, place it on a page, or share it.

Save, Undo and Deploy

Native app source and settings go live on Save after validation. File renames, imports and edits stay together until that Save succeeds. A failed build keeps the live app running and your local edits available. One previous accepted native build is available through Undo; Undo still respects current permissions and never restores revoked account consent.

Git apps use Deploy for source changes. Saving tool settings applies them without rebuilding or restarting the container. When an app changes, an older tab keeps its input and offers Reload. Failed calls are never replayed.