Skip to main content
Publishing records an immutable version of an App: its code commit, Compute Environment, data configuration, and identity settings. Publishing doesn’t start the App. Deploying does. You can deploy any version later, including an older one.

​
How publishing works

Domino resolves the Git reference to a commit, pins it, and records the version in the App’s history. The version takes its settings from your last preview, so you publish the configuration you tested. Uncommitted changes aren’t part of it. Publishing changes nothing for viewers. The running version keeps serving until you deploy another one. The Draft App and Workspace stay as they are, so you can keep working and publish again. The first publish creates the App. Each later publish adds a version to that App. A new version must come from the same Project and use the same entry point as the App.

​
What a version captures

An App’s settings fall into 4 groups. The group tells you whether a change needs a new version and whether it restarts the running App.

​
Why version-defining content is immutable

A version’s code commit, Compute Environment revision, Data Plane, data mounts, and extended identity propagation can’t change after you publish. Immutability serves two purposes:
  • Reproducibility. Deploying a version, today or months from now, runs the same code in the same environment with the same data configuration. Rolling back to an earlier version restores the code, environment, and data configuration viewers had before.
  • Governance. Reviewers approve a specific version, and that version can’t change after they approve it. What runs for viewers is what was reviewed.
To change any of these fields, publish a new version.

​
Why the entry point is fixed

Every version of an App starts from the same entry point and code configuration type, so any version can replace any other when you deploy or roll back. Domino rejects a version whose entry point or code configuration type doesn’t match the App’s. To change either, publish a new App.

​
Why deployment settings aren’t part of a version

The Hardware Tier, autoscaling, custom URL, and rendering settings control how a version runs, not what it runs. You can resize the App or change how it scales without publishing. These changes restart the running App. Version Notes and Tags describe a version, so they change without a new version or a restart.

​
Connect data to a version

Changing the Dataset, NetApp Volume, or External Data Volume mounts creates a version. A version reads the current contents of its data each time it runs. The transaction review App scores the latest transactions.csv even though its code is pinned.
  • Datasets mount read and write when your administrator enables com.cerebro.domino.dataset.mountingEnabledInApps. Otherwise, Apps reach Datasets only through the API.
  • NetApp Volumes mount read and write.
  • External Data Volumes mount inside the App container.
Mounted data uses the publisher’s permissions. Every viewer reaches it as the publisher. If viewers must see only their own data, scope mounted data to each viewer.

​
Publish the App

These steps publish the Synthetic Transaction Review App you previewed in Develop and test. Commit your code first, because Domino pins the latest commit.
1

Publish from the Workspace

In the Workspace where you previewed the App, select Publish App. This is the transaction review App’s first version, so publish it as a new App.
2

Describe the App

Name the App Synthetic Transaction Review, then write a description. The description is what viewers see when they browse Apps, so it decides whether viewers find and open your App. See Make the App easy to find.
3

Publish the version

Publish. The version now exists and nothing is running; deploying is a separate decision. Continue with Govern if your organization reviews Apps before release, or with Deploy.

​
Publish from a file without a Workspace

If the App code already works and you don’t need a preview, create the App and its first version in one pass. On the Project’s Deploy > Apps & Agents page, select Create, then Create from file. You set the version-defining content that a preview would otherwise supply. Domino creates the App and its first version with no Workspace or Draft App. The App isn’t running yet. Use this path to script releases or republish a known-good commit. If you haven’t run the code as an App before, preview it in a Workspace first. To change the App later, reopen it in a Workspace.

​
Make the App easy to find

Viewers see a card for each App they can discover. The card shows the title and description. The description tells viewers what the App does before they open it, so write one for every App you share.
  • Title: Name the App for its purpose, such as Synthetic Transaction Review or Marketing ROI Dashboard, not test-app or new-dash-demo.
  • Description: Say who the App is for, what data it uses, and what it assumes. For the transaction review App: who reviews, where the transactions come from, and that the model is synthetic.
  • Version Notes: Say what changed in this version. The notes and the pinned commits are the record of each change.
  • Tags: Tag versions so viewers and scripts can filter the App list.
  • Supporting documentation: Link to the wiki or guide that explains the data and the model, and consider an in-App link to it.
  • Feedback channel: Domino adds an Email Owner option to the App toolbar. For shared tools, also show a team alias or support channel in the App.
Version Notes and Tags can change at any time without a new version or a restart.
Last modified on October 27, 2026