Skip to main content

Publish and deploy Builder apps

Use the Publish panel when an app is ready to move from internal iteration toward a shareable URL or deployment workflow.

Publishing should happen after the app is healthy in preview and after your team has reviewed problems, security, and cloud state.

What the Publish panel can include​

Depending on your workspace, plan, and enabled integrations, the Publish surface may include:

  • OXVO-hosted app or preview URLs
  • static-first publishing controls
  • public or private access settings
  • custom domain configuration on supported paid workspaces and hosted deployments
  • GitHub connection and repository sync
  • Vercel or other deployment-provider handoff where enabled
  • collaborator setup
  • update, copy, open, or unpublish actions

Start with preview health​

Do not treat publishing as the place to discover basic app issues.

Before publishing, review:

  1. Preview for the main user journey.
  2. Problems for build and runtime issues.
  3. Security for obvious risk signals.
  4. Cloud if the app depends on Builder Cloud auth, database, storage, secrets, or backend operations.
  5. Auto Improve if connected product signals are expected to influence future changes.

Publish to a shareable URL​

For supported hosted publishing flows:

  1. Open the active app.
  2. Confirm the app works in Preview.
  3. Open Publish.
  4. Choose the available hosted publishing option.
  5. Set the app URL or subdomain if prompted.
  6. Choose public or private access if the option is available.
  7. Publish the app.
  8. Open the live URL and re-run the critical path.

If your workspace supports OXVO app domains, choose a clear subdomain that matches the app or team purpose.

Use custom domains carefully​

Custom domains may be available on supported paid workspaces and hosted deployments.

Before connecting a custom domain:

  • confirm the app is ready to be shared externally
  • verify the domain owner and DNS access
  • review whether the app needs authentication
  • confirm any Builder Cloud dependencies are configured correctly
  • test the published app after DNS changes complete

Connect GitHub for source control​

GitHub is the foundation for most production Builder workflows.

From Publish or App Details, you can:

  • connect the app to GitHub
  • confirm the repository mapping
  • add collaborators to the linked repository
  • keep generated code connected to normal developer workflows

If the app matters beyond a quick prototype, connect GitHub early.

Deploy through connected providers​

Some workspaces can connect deployment providers such as Vercel.

A typical deployment flow is:

  1. Connect GitHub.
  2. Open Publish.
  3. Connect the deployment provider for the active app.
  4. Review deployment settings.
  5. Deploy.
  6. Use the provider dashboard for environment, logs, and advanced deployment inspection.

If a deployment option is not visible, confirm that the required integration, plan, or GitHub connection is available for the workspace.

Static-first expectation​

Builder publishing should be treated as static-first unless your app is explicitly using Builder Cloud or another supported backend path.

Do not assume published apps include arbitrary long-running backend hosting by default.

If the app needs auth, database tables, file storage, secrets, APIs, scheduled work, or server-side business logic, enable and review Builder Cloud before publishing.

Public vs private access​

If access controls are available in your workspace:

  • use Private for internal review, staging, or team-only apps
  • use Public only when the app is ready for external viewers
  • re-check sensitive routes before switching an app from private to public

Update or unpublish an app​

Use update controls when the app should keep the same live URL but receive a newer build.

Use unpublish when the app should no longer be reachable from its published URL.

Before unpublishing:

  • confirm no team, customer, or integration depends on the URL
  • archive relevant app context
  • keep GitHub or project backups if the app may return later

Collaborators and handoff​

GitHub collaborators are useful when the app needs:

  • code review
  • shared ownership
  • deployment approvals
  • longer-term maintenance outside a single Builder session

Builder helps start the collaboration flow, but code review, branch governance, and production release policy still happen in your development process.

  1. Confirm the app works in Preview.
  2. Fix open issues in Problems.
  3. Review Security findings.
  4. Enable and verify Builder Cloud if the app needs managed backend infrastructure.
  5. Confirm support and session context if the app will be connected to OXVO Inbox or Sessions.
  6. Connect GitHub if the app matters long term.
  7. Configure hosted publishing, custom domain, or deployment provider.
  8. Publish or deploy.
  9. Re-run the critical user path from the live URL.
  10. Document ownership, update process, and rollback path.