Skip to main content
Each Domino App is defined at the project level and runs in its own isolated environment, so you can configure, start, and stop it without affecting Jobs, Workspaces, or other Apps in the same project. You control how it runs; Domino manages the orchestration.

​
App structure

An App’s settings fall into groups based on whether they are fixed for the App, define a version, or remain editable on a version. The entry point is the App’s launch file: a shell script such as app.sh, or a Python or R script. A typical launch file starts a process that binds to 0.0.0.0 and serves traffic on port 8888. An App that doesn’t expose a server on that address and port fails to start.
The entry point is fixed for the life of an App. To change it, create a new App.

​
App lifecycle

Development, publication, and deployment are separate, so each can happen independently.
1

Create

Define the App in your project, in a workspace or from an existing file. The App exists as an entity immediately, but creating it doesn’t make it reachable. See Create an App.
2

Develop and preview

Work on App code in a workspace and use Preview to run your Draft App in a real App runtime, with production networking, authentication, and environment variables, without publishing. Only the App author sees a preview, and it never collides with a deployed version. See Develop and test an App.
3

Publish

Promote the Draft App to a published App, either a new App or a new version of an existing one. Publishing records the configuration immutably, including the resolved commit, but doesn’t start the App.
4

Deploy

Start a published version to make it available to viewers. Each start creates an instance. You can deploy the newest version or any earlier one. See Publish and deploy App versions.
5

Stop

End the running instance and release its compute resources. The version and its history remain available.
Publishing and deploying are independent: publish several versions before deploying any of them, or redeploy an older version at any time.

​
Start an App version

Starting a version makes Domino provision resources and run the version’s settings:
  • Container provisioning: Domino creates a Kubernetes pod using the version’s Compute Environment and the deployment’s Hardware Tier.
  • Launch file execution: The container runs the entry point.
  • Monitoring and uptime: Domino monitors the process to keep the App available. If the App exits or crashes, Domino may restart it automatically depending on platform settings.
  • Secure proxying: All requests go through Domino’s proxy, which authenticates users, applies access controls, logs requests, and injects headers such as domino-username and the route prefix.
Starting or stopping an App never creates a version. Publishing a Draft or editing version-defining content creates one. Domino records each start as an instance in the version’s history.

​
Autoscaling Apps

Apps can scale automatically in response to user demand.
  • Pod replicas: Domino uses Kubernetes to add replicas of the App container when traffic increases.
  • Load balancing: Requests are distributed across replicas to maintain performance and responsiveness.
  • Dynamic behavior: Scaling occurs while the App is running, with replicas added or removed based on current load.
This lets Apps serve more users without manual resource changes. Autoscaling is a deployment setting, so changing it restarts the running instance rather than creating a version. Autoscaling Apps has guidance on tuning frameworks and resource allocation.

​
Stop an App

Stopping an App ends the instance and releases its resources:
  • Container shutdown: Domino terminates the Kubernetes pod and releases the assigned compute resources.
  • Data persistence: Any unsaved file changes are lost.
Logs and resource consumption recorded during the instance stay attached to the version. Unlike Jobs and Workspaces, Apps don’t automatically persist outputs, so use Datasets or external storage if you need to save results.

​
Next steps

Last modified on September 3, 2026