Skip to main content
A Domino App is a web application built from the code in your Project, in Streamlit, Dash, Flask, Shiny, or any other web app framework. Domino runs it, gives it a URL, and controls who can open it. An App is how you put a model, analysis, or data in front of the people who need to use it. Instead of sharing a notebook or exporting results, you host an interactive web front end, such as a dashboard, a calculator, or a review queue, that colleagues open in a browser. They don’t need access to your Project or any knowledge of the code behind it. You develop an App in a Workspace, using the same Compute Environment, Datasets, and Data Sources as the rest of your Project, and test it in App Preview before anyone else can see it. From there, the App follows a defined lifecycle: publish an immutable version, pass any governance approvals your organization requires, then deploy it to a URL on the Hardware Tier you choose. Autoscaling, rollback, and access controls work on the deployed App, so you don’t rebuild anything when traffic grows or the audience changes. Because every App goes through the same lifecycle, an App built for one team can be shared across the organization without being rebuilt or hosted again. The controls that matter in a regulated environment, such as versioning, approvals, and audit history, are built into publishing and deploying. This section follows one App from first commit to production: the Synthetic Transaction Review App from Get started. It’s a Dash App that reads transactions from a Dataset, scores them through a model endpoint, and records a reviewer’s decision. Each page starts where the previous one ends.

​
The App lifecycle

1

Develop and test

Write the App in a Workspace and run it in App Preview, a private App runtime that only you can reach. See Develop and test.
2

Publish a version

Publishing records an immutable version with the code commit, Compute Environment, and data configuration pinned, so every deploy and every governance approval applies to exactly the same App. Publishing doesn’t start the App. Give the App a description, because it’s what viewers see when they browse Apps. See Publish.
3

Govern

If your organization reviews Apps before release, attach a governance policy. Its gates block deployment until the approvals are in. See Govern.
4

Deploy to production

Deploy a published version to start it at its URL. Pick the Hardware Tier and, for heavy traffic, turn on autoscaling. See Deploy to production.
5

Operate

Share the App, watch usage and resource consumption, roll back to an earlier version, and troubleshoot failures. See Operate.
Before you write code, pick a framework in App frameworks: Streamlit, Dash, Flask, Shiny, Rust, or static HTML.

​
Persist what the App writes

Apps persist results in Datasets, databases, object stores, or APIs. The App container’s local disk is scratch space: Domino doesn’t save file changes from an App back to the Project, and whatever is on local disk is gone when the App stops or restarts. The transaction review App as built in Get started keeps each Approve or Flag decision in the browser session. Close the tab and the decisions are gone. Write anything you need to keep to one of these:
  • A Dataset. Write generated files, logs, and results to a mounted Dataset. Datasets are versioned separately from Project files, and other Apps, Jobs, and Workspaces can read them. The transaction review App can append each decision to a file in its AML Dataset.
  • A database or object store. Use the normal client library for your SQL or NoSQL database, Amazon S3, Azure Blob Storage, or data warehouse. The App needs credentials and network access.
  • An API. Call an internal or external API to record state or trigger a workflow.
A running App can also read mounted Datasets, NetApp Volumes, and External Data Volumes (EDVs), reach Data Sources, and use Project environment variables and the user environment variables of whoever starts the App. Publish covers how mounts attach to a version.
An App serves many viewers at once, and Domino doesn’t serialize their writes. Write to per-viewer locations, or use locks or atomic operations when viewers share one file or table.

​
Who the App runs as

An App reads data and calls Domino as its publisher. Every viewer sees what the publisher can see, and anything the App writes, the publisher wrote. Sharing controls who can open the App, not what the App can reach. When viewers must see or do different things, Identity passes the viewer’s identity into your code. Extended identity, which gives the App a token that acts with the viewer’s own permissions, supports the widest range of Apps and is the recommended level. An App that only needs its owner’s identity to run doesn’t need it. Decide while you develop, because extended identity changes how the App is published.

​
Run heavy work from an App

Apps run persistent and large-scale workloads through the other execution types Domino provides. When a request needs more compute or more time than a web request should take, the App starts a Job or calls a Domino endpoint through the Domino API, then shows the result when it’s ready. The App can do this as its publisher or, with extended identity, as the viewer. A deployed App runs until you stop it, across restarts, upgrades, and rollbacks, and separate executions are the better design for the heavy work behind it. Running a web front end and a long computation in one process is the weaker design: one long computation blocks every viewer, the pod is sized for the worst case, and the run has no record of its own. A Job runs on its own Hardware Tier with its own logs and reproducibility record, and an endpoint is its own deployed service with its own compute and logs. The App stays responsive for hundreds of viewers while a full model run or a long simulation uses the compute it needs, and every run is tracked on its own for audit and rollback. The transaction review App already works this way: scoring runs on a model endpoint, not inside the App.

​
How Domino models an App

Domino separates developing an App, recording a version, and running it. You can preview changes without publishing, publish without deploying, and deploy any published version, including an older one, without creating a version. That separation lets you work on the next version while viewers use the current one, review a version before it runs, and roll back without touching code.
Every version runs the same entry point, the App’s launch file: a shell script such as app.sh, or a Python or R script. It must start a web server on 0.0.0.0, port 8888. The entry point is fixed for the life of an App. To change it, create another App. Publish lists which settings create a version and which you can change in place.
  • Get started: Build the transaction review App, its Dataset, and its model endpoint from scratch.
  • App frameworks: Choose a framework and start from a minimal example.
  • Configuration: The feature flags and limits administrators control.
Last modified on October 27, 2026