Preview, publish and 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

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

The frontend self-check after every deploy

Once a deploy finishes, one more step runs automatically — it shows up as Frontend self-check. It opens the page you just deployed in a real browser and looks for the things that break it in front of a user: JavaScript errors, failing APIs, a blank first screen, text whose colour is too close to its background to read.

Why it exists: a successful deploy only proves the service started, not that the page renders. A wrong asset path, a dead API, one uncaught exception in a script — all three still return a perfectly normal response, and the page is blank when you open it. Until now the only way to find out was to notice it yourself and ask why the page was white.

There are three possible outcomes, all written into that step:

• Passed — nothing fatal. There may still be a few notes (low-contrast text, for instance) that do not block anything
• Problems found — it lists what broke and on which page. Do not publish yet; go back to the chat and ask for a fix
• Not run — the address was unreachable or the check could not execute. This means neither "the page is fine" nor "the page is broken" — it simply was not checked this time

The self-check never blocks a deploy; the deploy has already happened. It puts the verdict in front of you before you click Publish. API-only apps (whose root returns JSON rather than a web page) are detected automatically and are not reported as blank.

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:

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

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

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