---
title: "Publish to an Evonx address"
description: "Go live on your own evonx.app slug with versions, rollback, and suspend/resume."
url: https://evonx.ai/docs/launch/publish-to-evonx
locale: en
updated: 2026-09-04
---

# Publish to an Evonx address

Go live on your own evonx.app slug with versions, rollback, and suspend/resume.

Publishing takes what's in your repositories and puts it in front of real users on
Evonx's managed hosting — an `.evonx.app` address, HTTPS included, no servers to
configure. Every publish is a numbered version, and any version can be rolled back
to in one click.

## Publishing a release

1. **Merge what belongs in the release.** Publishing deploys your repositories'
   current state, so land the [pull requests](/docs/evolve/publishing-changes) you
   want included — one or several.

2. **Publish** from your project. Evonx builds the web app and API from source,
   provisions what they need — including the
   [managed database](/docs/launch/managed-database) — and swaps traffic to the
   new version when it's ready.

3. **Verify live.** Open your app's URL and walk the flows you changed. The app
   runs at `yourapp.evonx.app` until you attach a
   [custom domain](/docs/launch/custom-domains).

## Versions and rollback

Each publish creates an immutable version in your release history — what was
deployed, and when. If a release turns out bad in production:

- **Roll back** to the previous version. This is a fast switch of what's serving
  traffic, not a rebuild — the practical fix while you sort out the cause.
- **Fix forward** by asking a thread to correct the problem, then publish again.
  Rollback buys calm; the follow-up thread restores the feature.

> **Note**
> Rollback changes which app version serves traffic; it does not rewind your
> database. A release that migrated the schema needs the fix-forward path — one more
> reason schema changes get rehearsed in
> [preview databases](/docs/preview-and-debug/preview-databases) first.

## Cadence

Publish when something is worth shipping — after each merged thread, or batching a
week's merges into one release. Small, frequent releases keep the diff between
versions small, which makes both verification and rollback decisions easier.

You can also **suspend** a published app (it stops serving) and **resume** it
later without losing versions or the database. Use that when you need the URL
quiet without deleting the app.

## Related

- [Publish your app](/docs/get-started/publish-your-app) — the first-publish
  walkthrough from Get started.
- [Monitoring & publish metrics](/docs/launch/monitoring) — watching the release
  after it's live.