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

Ask for the change in a chat and let the agent finish
Click Preview and actually click through the test domain
Not right? Follow up in the same chat and preview again
Happy? Click Merge into the app's main version
Click Publish and wait for it to succeed
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 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:

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

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 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 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.