Publish an app

Building and publishing are separate on purpose. Build mode changes the project you review in Preview. Publish is the button that releases an approved version for customers.

This separation gives you a safe place to experiment. You can add features, compare designs, restore a version, and test sample data without changing the address customers already use. Publishing is the explicit moment when an authorized person chooses the development result that should become a production release.

The publish flow also prepares the environment the app actually needs. A static site can use an edge-hosted route, while an app with logins and durable records may require compute and Postgres. Mango9 guides this setup from the project it inspects; you do not have to decide from source code.

Example: Finish a new appointment-reminder feature in Preview on Tuesday, let staff test it Wednesday, and publish the approved version Thursday. Customers continue using the earlier production release until Thursday.

Try the main workflow in Preview before publishing. A live release should be a version you have already opened and used.

Before you press Publish

Use this short checklist:

• Is the latest Preview the version you want?
• Can a user finish the app's most important task?
• Does it look right on desktop and mobile?
• Are required connections saved under Integrations or Environment Variables?
• If the app saves real information, is a production database connected?
• Is your plan active?

Run the most important workflow as a user, not only as the person who requested the build. Use realistic data, test a failure or empty state, and check the mobile surface when customers may use phones. A short release review now is easier than repairing a live problem later.

Confirm integrations by name and environment. A connected test credential can make Preview appear correct while remaining unsuitable for real transactions. Likewise, a dynamic app can look ready but still need a durable production database.

Example: For a paid booking flow, create a test appointment, cancel it, verify the confirmation message, and confirm that production will use live payment and email credentials before publishing.

First publish, step by step

The first publish creates the production relationship for the project. Read each page rather than clicking through automatically: the app classification, database requirement, compute choice, and live address have different consequences. The process can continue on the server while you navigate elsewhere, and Production Cloud shows the authoritative state.

After the release succeeds, open the live address separately from Preview. This prevents a development session or cached preview route from being mistaken for production. Test the critical path once more against the live environment.

Example: Publish a CRM, open its new mango9.app address in a private browser window, sign in with a test production user, and save one test lead.

Choose Publish in the project header or open the project's Production Cloud page in Console. Mango9 explains whether the project is a simple static site or a dynamic app that runs on a server. Choose production compute and connect Postgres only when the app needs them. Confirm the release. The work continues on the server even if you leave the page. Test the important customer path at the new mango9.app address.

Why some apps need a database

A brochure site can publish as pages and images. A CRM, booking tool, portal, marketplace, or app with logins usually needs to remember information after someone closes the browser. That information belongs in a production database.

The question is not whether the app has a form; it is whether the submitted information must remain available and consistent for people later. A contact form that only sends an email may not store business records. A customer portal that displays orders across sessions clearly does.

Example: A public menu with fixed prices can publish without Postgres. A restaurant waitlist that adds names, updates table status, and serves several hosts needs durable shared data.

Easy way to tell

If customers create accounts, save records, book appointments, change statuses, upload files, or return to information later, the app probably needs a database.

Static and dynamic—in plain language

Fits marketing sites, portfolios, public information, and other pages that do not need server-side persistent customer activity. Static projects can still be polished, responsive, interactive, and multi-page. Fits logins, dashboards, shared records, payments, bookings, private portals, and workflows that run server logic or save durable data. Dynamic production may require compute, environment variables, integrations, and Postgres.

Mango9 checks the project and guides you to the fitting route. You do not have to decide from code.

Static does not mean visually simple, and dynamic does not mean automatically better. A polished multi-page portfolio can be static. A compact one-page operations dashboard can be dynamic because it signs users in, calls server routes, and saves records. Choose the route that matches behavior.

Example: An interactive mortgage calculator that forgets the result may remain static. Saving calculations to customer accounts makes it dynamic.

Publish a newer version

Continue building in development. When the next result is ready, use Publish New Version. A dynamic release keeps its production database while the application version is updated.

Treat every new version as a small release: review the saved development result, verify any new variables or schema needs, publish, and test the live path. The existing production release remains the customer version until the new publish completes.

If the new release causes a customer-impacting problem, Production Cloud can offer rollback to an earlier deployment. That is separate from restoring a development version in Studio.

Example: Version 12 adds invoice export. Publish it only after export works in Preview and the production user role is confirmed. Roll back production if the live export unexpectedly blocks invoice viewing.

If Publish is waiting

A waiting state protects the release from an unmet requirement or overlapping operation. Read the specific message and resolve that one condition. Repeatedly starting Publish does not make a database, plan, or active deployment finish faster.

Example: “Connect database” means the inspected app needs durable production data. It does not mean you should ask Build to hide the message or convert the CRM into a static site.

| What you see | What it means | What to do | |---|---|---| | Plan required | Publishing is not included in the current account state. | Open Plans and choose or restore a plan. | | Connect database | The app saves information but has no production database yet. | Add the Postgres connection and try again. | | Latest build not ready | The current project result needs review or another focused pass. | Read the completion card and correct the named issue. | | Another operation is active | Mango9 is already working on this project. | Let that action finish first. | | Analyzing project | Mango9 is checking the project before choosing a release route. | Keep the page open and wait for the result. |

Typing “publish this” into Build chat does not replace the protected Publish control and may spend credits on unnecessary work.

Learn Production Cloud Connect a domain