---
title: Publish with Thally managed hosting
description: Understand production releases, pull-request previews, content-only publishes, rollbacks, domains, and runtime upgrades.
url: https://pr-6-a9c4e9fe1b6c.thally.app/guides/managed-hosting
---

# Publish with Thally managed hosting

Understand production releases, pull-request previews, content-only publishes, rollbacks, domains, and runtime upgrades.

Managed hosting turns each approved Git revision into a release that cannot
change after validation. A failed publish leaves the previous healthy release
online.

## What triggers a publish

- A push to the configured production branch creates a production candidate.
- Opening or updating a documentation pull request creates or refreshes an
  isolated preview.
- Merging a Track documentation pull request follows the same production path.
- Changing a supported setting or applying a runtime upgrade publishes a new
  release.
- **Redeploy site** rebuilds the current version; it does not upgrade the
  runtime.

The **Deployments** page shows the live production release, the latest preview,
open preview count, commit details, status, and searchable history.

## How a production release becomes live

#### Thally records the Git revision

    The Deployments page keeps the commit and source branch attached to the
    release, so you can tell exactly what is being published.

#### Thally validates the candidate

    The project is checked, built, and smoke-tested before it can become live.

#### The release becomes live

    A successful candidate replaces the current release in one step. If any
    check fails, the existing live site stays in place and the failure appears
    in deployment details.

## Content-only publishes

When a new commit changes only `docs.json`, `src/content/**`, or `snippets/**`,
Thally can reuse the validated site framework and publish the new content more
quickly.

The fast path is conservative. A force push, incomplete comparison, oversized
change, unsupported file, runtime change, or uncertain result falls back to a
full build. Falling back changes speed, not the validation contract.

## Pull-request previews

Each open documentation pull request receives a stable preview address and a
release for each revision. Its access settings and publishing state are
separate from production.

A preview is ready only after its validated release is selected by the preview
route. Closing or merging the pull request retires the route and schedules its
release files for cleanup. A preview cannot change the production route.

## Roll back safely

Owners and editors can select a previous validated release from deployment
history. A rollback moves the site route to that saved release; it does not
rebuild the site or rewrite Git history.

After a rollback, Thally pauses automatic production publishing. Pushes
received while publishing is paused are recorded as superseded, so a later build cannot
silently overwrite the rollback. Use an explicit publish to resume automated
production updates after you have resolved the problem.

## Add a custom domain

Open **Settings → Domains**, add the hostname, and copy the DNS records Thally
shows into your DNS provider. Thally provisions the certificate and serves the
same live release at both the custom hostname and the managed `thally.app`
address.

Keep the managed address available while the custom domain is pending. Wait
until the Domains page reports the custom hostname as verified, then open it
in a private browser session.

## Upgrade the site runtime

Thally publishes immutable starter releases. When a newer compatible release
is available, **Settings → Updates** shows **Update site**. Thally compares the
starter your site began with, the new starter, and your repository.

- Files that still match the old starter update automatically.
- Your pages, navigation, branding, and other authored files stay unchanged.
- If a framework file also has local edits, Thally leaves it alone and tells
  you which file needs review.

When the update succeeds, Thally commits the safe framework changes and queues
a publish. If the update needs review, run the commands below in a local
checkout. The first previews the plan; the second applies the changes after
you have reviewed them.

For a self-hosted project, preview the same immutable update locally:

```bash
npx thally starter update
npx thally starter update --apply
```

This same local flow works for managed and self-hosted projects.

## Verify a publish

1. Confirm the deployment is **Healthy** or the preview is **Ready**.
2. Check that the displayed commit matches the revision you expected.
3. Open the live or preview address and test a representative page.
4. Check `/llms.txt`, `/api/docs-index`, and `/AGENTS.md`.
5. If the release failed, open its details before redeploying or changing
   source files.