# Preview, publish, and what to watch after launch

How preview, merge and publish differ, what to do when a deployment fails, and where to watch traffic once your app is live.

Writing the code is only half the job — getting it in front of users goes preview, then merge, then publish.

## What preview, merge and publish each do

| Action | Where | Result |
|---|---|---|
| Preview | Under a chat message | Deploys this chat's changes to the **test environment**, reachable at the test domain |
| Merge into the app's main version | Next to the composer | Folds the changes into the repository's **default branch**; nothing changes for users yet |
| Publish | Under a chat message | Builds and deploys to the **production environment** |

The three are independent: you can preview without merging (try it and throw it away), or merge without publishing (batch several changes into one release).

> Code only goes live once you **publish** it. Merging just puts it on the default branch — until you publish, your production domain still serves the previous release.

## A sane release rhythm

1. Ask for the change in a chat and let the agent finish
2. Click **Preview** and actually click through the test domain
3. Not right? Follow up in the same chat and preview again
4. Happy? Click **Merge into the app's main version**
5. Click **Publish** and wait for it to succeed
6. Open the production domain and check once more

## Deployment records

Every preview and publish leaves a record. The deployment badge in a message, and the deployment history entry in the [Apps](#/apps) list, both open the deployment detail page, which shows:

- The environment (test or production), the status and how long it took
- The full build and deployment log
- An error summary when it failed

**You do not need to read the log yourself.** Say "the last publish failed, take a look" in the chat and the agent will pull the log and fix it.

## Publishing from the deployment page

The deployment detail page can publish to production too, and **you never pick a commit by hand**. Two routes:

1. **Publish straight from the default branch**
   - Select the app in the filter at the top — the **Publish to production** button only appears once one is selected
   - Write a release description (required, up to 512 characters) and submit
   - Quodara builds and deploys whatever the default branch currently holds
2. **Promote a build you already verified**
   - Rows with environment `Test`, status `Success`, and both Task ID and Chat ID at `0` get a **Go live** button
   - Those rows are the builds produced automatically when something was merged into the default branch
   - Click **Go live**, confirm, and that exact build is switched over to production

Use the second one when you have already clicked through the test environment and want that same build on production, unchanged.

## Published apps

[Published apps](#/published-apps) lists everything you have shipped to production — a single overview of what is actually live.

## After launch: the Board

The **Board** tab on the [Apps](#/apps) page shows how an app is doing in the real world, based on frontend monitoring, for up to the last seven days:

- **Traffic** — page views and sessions
- **Referral channels** — whether visitors arrived from search engines, AI assistants, social platforms or directly
- **Load performance** — first paint and key rendering metrics

You can set a default app so the Board opens on it. If an app has no monitoring wired up yet, the Board shows a warning with a one-click fix that has the agent integrate it for you.

## Why referral channels matter

People find products two ways now: search engines (SEO) and AI assistants recommending you (GEO). The Board separates the two, so you can see whether Google is sending more people than ChatGPT is, and decide where to invest.

To improve either number, ask the agent in a chat to strengthen your structured data, `sitemap.xml`, `llms.txt` and landing page copy. Driving traffic from outside is the other route — the agent writes publish-ready posts for each content platform, see `07-marketing.md`.

## Android: same buttons, different destination

Everything above is about the web target — preview goes to the test domain, publish goes to the production domain. If the app also ships an Android package, the same two buttons quietly do a second thing:

| You clicked | Web | Android |
|---|---|---|
| Preview | Deploys to the test domain | Builds a debug package you can install by scanning a QR code |
| Publish | Deploys to the production domain | Builds a signed release package |

Two differences worth remembering:

- **The package is not served from your domain.** The download entry point lives on your own page, and only appears once a build has succeeded *and* the app has been deployed again afterwards.
- **Build history and signing key export** live on the Android step of the app's configuration page.

The Android build hangs off the web deployment: if it fails, it is marked as failed and **the successful web release is not rolled back**. Full details in `09-multi-target.md`.

## Common questions

**Q: Is the site briefly unavailable while publishing?**
A: The build runs in the background, but replacing the running container at the end causes a short interruption. If that matters, publish outside your peak hours.

**Q: Something went wrong — how do I get back?**
A: Two options. On the deployment page, find an earlier `Test` + `Success` row you had already verified and click **Go live** to switch that build back onto production; or describe in the chat which change to undo and let the agent revert it and publish again.

**Q: Why can't I find my test environment in Google?**
A: Crawling is fully disabled on test environments. That is deliberate — you do not want test content indexed and competing with your production domain.

Read next: `05-misc.md`