Prepare for the rapid Go live flow

Rapid publishing is valuable only when the draft is ready. Use the editor’s computed checklist to remove predictable launch mistakes first.

1. Open Launch guide and complete the business details, hours, real photos, content, SEO, button destinations, and phone preview items it shows for this project.
2. Open Preview and test the Storefront at Desktop and Mobile. When the draft includes operational modules, test Backoffice too — the full delivery publishes it, so what you approve here is what staff will work in.
3. Use Review when another person must approve the draft or return feedback.
4. Wait for Saved before opening Go live.

In the browser product, publishing is a server-controlled workspace capability. Provider credentials belong on the server and should never be pasted into page content or browser storage.

1. Choose Go live in the editor top bar.
2. If the screen says publishing is unavailable, unauthorized, or not configured, stop and ask the workspace owner to enable it.
3. Do not substitute Export for a deployment. An export is portable output; it is not a server-confirmed live site.
4. Confirm the selected project. Naratake assigns the verified system URL only after the immutable release passes promotion checks; the browser does not invent a provider subdomain.

Naratake builds a full Next.js application with a database behind it, and most business modules — orders, reservations, appointments, customers — need that database running. Cloud publishing has two deliveries for that application. The full delivery provisions the site’s own Postgres database and its Backoffice, so those modules go live and the records customers create are stored. The storefront delivery is the same site with the write-side removed, and the publish report names every section it removed. Which delivery a workspace may request is decided on the server when the request is submitted, not by the browser: the full delivery needs a plan carrying both the commerce and bookings modules, which today means Storefront Pro. What the site itself will contain is still computed from the components and modules the saved revision actually delivers, not from its template label.

1. Read what Go live says this release will deliver: the site with its own database and Backoffice, or the storefront version of the same site.
2. If the business needs live orders, bookings, customer records, or an authenticated Backoffice, request the full delivery. A workspace whose plan does not carry the commerce and bookings modules is refused it before any provider work, and the refusal names the plan that carries it.
3. Do not remove a required business module merely to publish sooner. Either move the workspace to the plan that includes the full delivery, or publish the storefront delivery as a deliberate decision and keep the operation in Preview until then.
4. Do not substitute a desktop export, provider credential, or manual browser upload for a delivery the plan does not include.

Warnings may not block the deployment, but they describe issues a customer can see. Treat them as a deliberate sign-off list.

1. Open each warning and identify the affected page, content, module, or environment decision.
2. Fix customer-visible issues such as missing legal text, sample data, dead calls to action, or incomplete payment configuration.
3. When a warning is intentionally accepted, record who accepted it and why before submitting the launch.

A deployment can take time and can fail after partial work. The authoritative result is the status returned by the cloud service, not the initial click or an optimistic browser message.

1. Choose Go live once and keep the project open while progress is reported.
2. Do not repeatedly submit because a build appears slow. Refresh the deployment status or Releases area before retrying.
3. If the server reports an error, preserve its request or deployment identifier and exact message, correct the stated cause, then retry once.
4. Treat a simulation, rehearsal, preview, or pending status as not live.

The final check happens outside the editor against the returned public site and its real server behavior.

1. Open the returned URL in a private browser window and check the home page, navigation, legal links, and every call to action that this release actually carries.
2. Verify that the public content matches the reviewed revision rather than an older preview.
3. Announce orders, reservations, appointments, or the authenticated Backoffice only when this release actually carried them. The full delivery does — sign in to the Backoffice at the returned site and confirm the test record lands. The storefront delivery does not, and the publish report lists exactly what it removed.
4. Check the live URL on a phone and verify HTTPS before sharing it.

Saving changes updates the draft; it does not silently change the live site. Use Go live again when the next reviewed version is ready.

1. Make edits, wait for Saved, and repeat Preview plus any module-specific test.
2. Review changes to live modules as data-impacting decisions before deployment.
3. Choose Go live again and verify the returned status and URL just as you did for the first release.
4. Keep the previous working release available while the new release is still being verified.