Preview, approve and publish
Keep the everyday loop simple: make a change → try it → save a preview → make it live. Your builder can do the technical work; you decide whether the result is useful and ready.
Try the change locally#
A preview at 127.0.0.1 or localhost runs on your computer. It is useful for fast iteration, but it is not a saved MovePacket update and other people cannot open that address on their computers.
Ask your builder to test the main task and explain what changed. Check the controls, charts, empty states and mobile layout that matter to your users.
Save a MovePacket preview#
Save this change as a MovePacket update. Give me its private preview link, a short description of what changed, what you tested and what still needs checking. Keep the current live version until I approve.
A hosted project's Updates view shows saved candidates. Preview changes opens the exact saved files using your existing MovePacket owner sign-in. Later local edits do not change that preview; the builder must save another update.
Saved previews stay owner-only even when the live project is public. They do not have live private records, provider credentials or an application server runtime. Features depending on sign-in, live data, payments or email require separate testing. Supported public map tiles can still load.
Read the checks in context#
MovePacket checks the package's supported file limits, known credential patterns, stored-file integrity and whether the live base version has changed. Those checks do not prove that every interaction works or that the application is secure.
Functional review remains yours and your builder's responsibility. Independent code-review services are not automatically connected to customer projects. A platform repository's Greptile review does not review all customer software.
Make the reviewed version live#
In Updates, choose Make live for the version you checked. An authorised builder can publish that exact saved version after your approval too.
Publishing preserves the project's audience. A private project stays private; a public project remains public. Changing the audience is a separate choice under Access & sharing.
If another version is now live, publication stops rather than overwriting it. Ask the builder to pull the current files, reconcile the changes and save a new candidate. Open your project address after publishing and try the main task again.
Publish a Page to your Hub#
Your Hub is the list of published Pages at the top of your workspace menu. A Page shows one saved version of a private Project inside your workspace:
- In MovePacket AI, for a Page or a project set to Inside MovePacket, choose Publish the page.
- In a project's Updates, choose Publish to Hub on a saved version. Check the Page name and opening view, confirm you have tried that version and that it contains no credentials or personal-data snapshots, then choose Add to my Hub (Publish update to Hub when the project's Page is already there).
Only you, as the account owner, can open a Page. Live data is not connected. Later Project edits do not change the Page until you publish it again. Remove from Hub, in the project's Updates, takes the Page out of your menu; the Project and its saved versions remain.
Publishing to your Hub is separate from Make live. It does not change the project's address or who can open it, and a project cannot be made public while its Page is in your Hub. A Hub Page is also different from a Publish a page shared snapshot, which anyone with its link can open.
Restore an earlier version#
Previous published versions can be restored through the project's version workflow or the builder tool. This restores application files. It does not undo database changes, sent emails, payments or actions in another provider.
Before changing data structure, access or a paid integration, ask for the testing and recovery plan. See Protection & recovery.
A MovePacket AI creation is a different preview#
An in-workspace generated creation has its own saved versions and sharing controls. Publish a page creates a shared snapshot; it is not the same as making a hosted-project update live at your chosen address. Keep sample content in public snapshots. Use the project's hosting controls when publishing to your managed address.
Builder reference contains the commands for this workflow.