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 record type, 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, publish. Good for small interfaces 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 capabilities you grant it explicitly. An app declares which tools it wants; you approve them before publishing. 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 full-page at its own address, or embed it on a page or dashboard.

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 releasing

Open Apps and choose New app.

Any workspace member can create an app, rename it, change its source, and archive it. An app that has not been released runs nowhere, so authoring one is ordinary workspace work.

Releasing is a workspace admin's decision. Publishing an inline app, deploying a repository app, and rolling back all put executable code in front of everyone who opens the surface it sits on — a heavier act than editing a draft, and one Rollout keeps separate on purpose.

Each app's settings page shows its current release — image, digest, commit, port and health check — the release before it, and the last failed build's own error output, unedited. A build failure shows you what the compiler said, not a summary of it.

Rolling back swaps the current release with the previous one. Nothing is rebuilt.

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

• Inline apps: 256 KiB total, 64 files.
• 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 capabilities it needs, and review them.
4. Publish or deploy.
5. Open it, place it on a page, or share it.