# Publish your app

Source: /docs/building/publish-your-app.md

Publishing makes a working local app available through its hosted URL. The app and its backend resources have separate saved and deployed versions, so publish the pieces in dependency order.

A commit saves source. A build prepares a runtime or artifact. A run executes work. A deployment selects the version used by published consumers. These steps have different results; a successful preview does not automatically publish it.

## Prepare the data and backend first [#prepare-the-data-and-backend-first]

Before publishing the interface, check what it depends on:

| Dependency | What must be ready |
| --- | --- |
| Connector and sync | Saved configuration, deployed source versions, and a successful output for production consumption |
| Transform | Deployed version and a successful output from that version |
| Managed database | Required migrations applied to the environment the backend accesses |
| API | Deployed runtime, resolvable inputs, and a usable response |
| Assistant | Deployed definition, available context, attached documents, and usable deployed API tools |

Vortexify does not implicitly deploy every dependency. Your coding agent should inspect the resource references and publish upstream resources before their consumers.

For a transform-backed app, deploy the producer first, then start its production execution through the deployed app or production transform execution service and wait for successful output. Deploying the transform selects its production version but does not run it. The earlier CLI preview output does not substitute for output from the deployed producer version. Scheduled execution also depends on deployment; manual previews do not activate schedules or downstream production triggers.

## Publish the consumers [#publish-the-consumers]

Once dependencies are ready, your coding agent saves and deploys the API and app:

```sh
vortexify commit --type api --resource normalize
vortexify commit --type app --resource dashboard
vortexify deploy api normalize --wait
vortexify deploy app dashboard --wait
```

Use your project's actual resource names and deploy any required assistant before its app consumer. Inspect deployment results, then open the hosted app from the platform's **Apps** directory and try the main interaction while authenticated. The current workspace shows deployed versions and hosted app links; deployment commands remain in the CLI workflow.

App access is another release choice. The backend supports private/public app sharing and hosting-domain configuration, subject to permissions and plan features. Public app sharing and public conversation visibility are separate settings; a public conversation means the authorized project audience. The current frontend does not expose the full hosting/access configuration workflow.

A frontend build verifies compilation. A useful release check also confirms that the app can call its deployed backend and display the expected data, response, or conversation. Use the platform to inspect deployment state, output versions, and execution logs when an interaction differs from local preview.

> **Platform screenshot placeholder:** The published app and its deployment version, alongside the deployed backend resource and the successful output it consumes.

## Update deliberately [#update-deliberately]

After editing, review `vortexify status` and commit the changed resources. Use `vortexify upgrade TYPE NAME --wait` to update the deployments you intend to change. New commits do not automatically replace a published version.

For a producer change, check the downstream contract before upgrading its consumers. Published tabular consumers read the latest successful output belonging to the producer's deployed version. A new deployed version needs its own successful output; previous preview success is not enough.

Database changes have their own approval and applied-schema lifecycle. Follow [database migrations](/docs/building/store-app-data#saved-source-and-applied-schema-are-different-states) rather than assuming an app deployment applies SQL.

## Observe existing work before retrying [#observe-existing-work-before-retrying]

For asynchronous work, keep the job ID:

```sh
vortexify job JOB_ID --wait
vortexify logs JOB_ID
```

Inspect the terminal result and any output or validation findings relevant to the operation. Stopping or timing out a wait does not cancel backend work. Reconnect to the existing job before starting another run, especially when the operation writes records or calls an external system.

See [CLI execution](/docs/reference/cli/execution) for exact deployment, waiting, and inspection options.