App Structure and Lifecycle

Each Domino App is defined at the project level and runs in its own isolated environment. This isolation ensures that Apps can be configured, started, and stopped without affecting Jobs, Workspaces, or other Apps in the same project.

Apps are designed for interactive, user-facing workloads. You control how they run by selecting the compute environment, hardware tier, launch script, and code branch. Domino manages the underlying orchestration so your focus stays on the App logic.

This page covers two dimensions:

  • App structure - the elements that define an App and keep it independent from other project workflows.

  • App lifecycle - how Domino provisions, scales, and shuts down an App at runtime.

App structure elements

Each App in Domino is defined by four key elements. These settings give you precise control over how an App runs, while keeping it isolated from other workflows in the project. Projects can contain multiple Apps.

  • Launch File - The App’s entry point. It must start a process that binds to 0.0.0.0 and serves traffic on port 8888. Shell scripts (for example, app.sh) or Python/R scripts are commonly used. If the App does not expose a server on this address and port, it will fail to start.

  • Compute Environment - A container image that defines the runtime, including all required packages, libraries, and system dependencies. Each App can have its own environment version to preserve reproducibility.

  • Hardware Tier - The compute resources used to run the App, including CPU, memory, and GPU allocation. These choices determine performance and scalability, and can be tuned separately from Jobs or Workspaces.

  • Code Branch - The Git branch the App runs from (for Git-based projects). This allows you to version and isolate App logic from other workflows.

By combining these four elements, you can control exactly how the App executes without affecting other jobs, experiments, or collaborators in the same project.

App lifecycle

Domino manages the full lifecycle of each App, from provisioning to shutdown. The process includes starting the App, scaling it to meet demand, and stopping it when it’s no longer needed.

Start an App

Starting an App triggers Domino to provision resources and run your defined settings:

  • Container provisioning - Domino creates a Kubernetes pod using the selected Compute Environment and Hardware Tier.

  • Launch file execution - The container runs the Launch File. This script must start a process that listens on port 8888 from 0.0.0.0.

  • 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

    • Injects headers such as domino-username and the route prefix

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 model allows Apps to serve more users efficiently without requiring manual resource changes. App Autoscaling has detailed guidance on tuning frameworks and resource allocation.

Stop an app

Stopping an App releases its resources and ends its session:

  • Container shutdown - Domino terminates the Kubernetes pod and releases the assigned compute resources.

  • Data persistence - Any unsaved file changes are lost.

Unlike Jobs and Workspaces, Apps do not automatically persist outputs. Use Datasets or external storage if you need to save results.