Before you start
Bring the facts, not more tabs.
- Launch guide is complete except for Put it online.
- Preview has passed on Desktop and Mobile for the customer journey included in the draft.
- The workspace has cloud publishing enabled and the current account is authorized to publish.
- The project does not require a production database, live Backoffice records, payments, or another capability that the Go live eligibility check marks unavailable.
You will learn to
- Separate preview, review, export, and live deployment.
- Use launch checks as the final content-quality gate.
- Rely on server-reported cloud status instead of a button click.
- Verify the returned storefront and release marker before announcing launch.
Finish Launch guide and run the two review views
Rapid publishing is valuable only when the draft is ready. Use the editor’s computed checklist to remove predictable launch mistakes first.
- Open Launch guide and complete the business details, hours, real photos, content, SEO, button destinations, and phone preview items it shows for this project.
- Open Preview and test the Storefront at Desktop and Mobile. When the draft includes operational modules, test Backoffice too, even though today’s rapid publishing path cannot deploy the modules that need a database.
- Use Review when another person must approve the draft or return feedback.
- Wait for Saved before opening Go live.
Done when: The draft has no known sample data or broken primary action, and the saved version is the one the publisher intends to release if it passes the server eligibility check.
Open Go live and confirm cloud publishing is available
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.
- Choose Go live in the editor top bar.
- If the screen says publishing is unavailable, unauthorized, or not configured, stop and ask the workspace owner to enable it.
- Do not substitute Export for a deployment. An export is portable output; it is not a server-confirmed live site.
- 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.
Done when: The launch screen identifies the correct site and accepts an authenticated cloud publishing request without asking the end user for infrastructure secrets.
Confirm the site is eligible for the current publishing path
Naratake builds a full Next.js application with a database behind it, and most business modules — orders, payments, reservations, appointments, customers — need that database running. Today the rapid path can only ship the part of a project that runs without one, such as catalog pages, reviews, and written content, because the managed database service is not wired up yet. Eligibility is calculated from the components and modules the saved project will actually deliver, not from its template label, so any project that needs the database stops before the builder, artifact store, or hosting provider is called.
- Confirm that Go live identifies the delivered project as needing no database and describes an isolated build.
- If the project requires live orders, bookings, customer records, payments, authenticated Backoffice, or another database-backed module, stop when Naratake reports that it is not eligible.
- Do not remove a required business module merely to pass the gate. Keep testing the complete operation in Preview until the managed data service is available.
- Do not substitute a desktop export, provider credential, or manual browser upload for the blocked cloud path.
Done when: The project either runs without a database and is eligible, or the launch has stopped safely with no provider work and no false live claim.
Read every Launch checks warning
Warnings may not block the deployment, but they describe issues a customer can see. Treat them as a deliberate sign-off list.
- Open each warning and identify the affected page, content, module, or environment decision.
- Fix customer-visible issues such as missing legal text, sample data, dead calls to action, or incomplete payment configuration.
- When a warning is intentionally accepted, record who accepted it and why before submitting the launch.
Done when: Every warning is either resolved or explicitly accepted by an authorized owner with a known customer impact.
Submit once and follow the server-reported status
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.
- Choose Go live once and keep the project open while progress is reported.
- Do not repeatedly submit because a build appears slow. Refresh the deployment status or Releases area before retrying.
- If the server reports an error, preserve its request or deployment identifier and exact message, correct the stated cause, then retry once.
- Treat a simulation, rehearsal, preview, or pending status as not live.
Done when: The deployment reaches a server-confirmed ready or live state and returns a URL for this exact project revision.
Verify the live URL before announcing it
The final check happens outside the editor against the returned public site and its real server behavior.
- 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.
- Verify that the public content matches the reviewed revision rather than an older preview.
- Do not announce orders, reservations, appointments, payments, or authenticated Backoffice as live through this release path; it does not carry them yet.
- Check the live URL on a phone and verify HTTPS before sharing it.
Done when: The public URL serves the reviewed revision over HTTPS and every supported customer action behaves as expected.
Publish later edits as a new verified run
Saving changes updates the draft; it does not silently change the live site. Use Go live again when the next reviewed version is ready.
- Make edits, wait for Saved, and repeat Preview plus any module-specific test.
- Review changes to live modules as data-impacting decisions before deployment.
- Choose Go live again and verify the returned status and URL just as you did for the first release.
- Keep the previous working release available while the new release is still being verified.
Done when: The live site changes only after a new reviewed, server-confirmed publishing run.
Final check
Do not call it done until these are true.
- Launch guide and Desktop plus Mobile Preview passed on the saved draft.
- Cloud publishing was enabled and the publisher was authorized.
- Every launch warning was resolved or explicitly accepted.
- The server reported a live state and returned the expected URL.
- The published pages, phone view, release identity, and HTTPS were verified.