Define done before opening the publish dialog
Write one sentence naming the release outcome:
An employee in the intended role can open the deployed URL, complete the critical workflow against approved non-production or company data, and reach a named operator when it fails.
Then record the approved fixture, intended users, business owner, operating owner, source location, production configuration owner, and critical workflow. If those fields are unknown, the publish action is premature.
Choose one safe workflow that reaches the dependencies coworkers need. A homepage load cannot reveal a broken login, database connection, or required API. Suppress email, payments, webhooks, and other external effects unless the exercise explicitly approves them.
Choose the documented publish and access mode
Replit documents Publishing as a snapshot of the app's files and dependencies running separately from the Project Editor. It offers different deployment types for different workloads and says access controls are available only to some plans. Record the selected deployment type and the effective audience; do not write “private” merely because the editor project is private.
Lovable documents publishing as a deployed snapshot at a live URL. Its current publishing guide says Free and Pro published sites are reachable by anyone with the link, while Business and Enterprise can use workspace or custom audiences. Record the actual plan, audience selection, and who may change it. A basic provider security scan is a signal to inspect, not proof that the application is secure or approved.
For either platform, answer:
- Is this deployment public, link-accessible, workspace-only, or custom?
- Who may publish and who may change the audience?
- Which source project or repository produces the release?
- Which configuration belongs only to production?
- What identifier lets an operator recognize the deployed revision?
Preserve source and release identity
A receiver should be able to move from the deployed app to the source and change history without relying on the original builder's memory. Lovable's GitHub integration documentation describes a synchronization path; Replit documents each publish as a new snapshot. Neither fact proves that your team retained the right repository, reviewed the diff, or can identify what is live.
Record the project or repository owner, reviewed revision, publish time, publisher, and provider-side verification location. Prefer an immutable commit or artifact identifier over a label such as “latest.” If the running revision cannot be identified, stop the handoff rather than guessing.
Test the deployed URL outside the builder preview
Open the deployed URL in a new browser session as an intended test user. Replit explicitly recommends repeating checks at the published URL because behavior can differ from Preview. Apply the same boundary to either provider.
Record six direct observations:
- The deployed URL opens outside the builder or editor preview.
- The intended user can complete the critical workflow.
- An anonymous or unintended user receives the expected bounded response.
- The displayed or diagnostic revision matches the release record.
- A controlled failure leaves useful evidence in a safe log or dashboard.
- The previous release or unpublish path can be located without executing a destructive production action.
A provider success message is not the result of these checks. Retain links or screenshots that omit credentials, private records, and copied production logs.
Separate reversal from data recovery
Write down how to stop exposure, restore the prior application revision, and escalate an incident. Replit republishes a fresh snapshot when an app is updated; Lovable documents publishing changes and unpublishing. Verify the current procedure for the selected project before relying on it.
Reverting application code does not restore deleted or corrupted records. Keep the database backup and restore owner in a separate runbook. If a release changes the data contract, record whether the previous code can still read the new state.
Use the deployment handoff card
Copy the evidence card from this guide's research packet and complete it during the exercise:
| Check | Evidence | Observed result | Gap and owner |
|---|---|---|---|
| Deployed URL outside preview | |||
| Intended workflow | |||
| Unintended access | |||
| Running revision | |||
| Safe failure evidence | |||
| Reversal path |
The final decision is accept, accept with named corrections, or stop. Do not average a missing access control or unknown owner into a passing score.
Evidence boundary for this draft
On August 4, 2026, the accompanying local rehearsal successfully produced separate production and noindex preview builds for the Garden content network. It did not deploy a Lovable or Replit fixture, open a provider URL, test a coworker role, inspect provider logs, or exercise reversal. This review version therefore publishes no provider result; complete the card before treating a particular release as verified.
Verification checklist
- Approved platform, plan, deployment mode, and audience are recorded.
- Business, configuration, operating, and escalation owners are named.
- Source revision and deployed revision can be compared.
- Intended and unintended access were tested at the deployed URL.
- The critical workflow was repeated outside preview.
- Safe failure evidence and the reversal path were located.
- Data recovery remains separate from application reversal.
- An internal-tools product owner signed the handoff card.
Frequently asked questions
Is a private editor project the same as a private deployed app?
No. Record and test the published website's effective audience. Provider plan and workspace settings can change which access choices are available.
Does a passing provider security scan approve the app?
No. Treat it as one input. The application still needs effective access tests, data-boundary review, critical-workflow evidence, owners, and recovery.
Can we share the URL before the handoff is complete?
Limit sharing to the approved test audience. Stop broader rollout when the access boundary, live revision, operating owner, or reversal path is unknown.