For a Wix-managed Headless project, what is the supported way to revoke, disable, or set an expiry on an old deployment URL created by wix preview?
wix preview --help describes creating a preview, but I cannot find a command for listing or retiring existing previews, or an equivalent control in the dashboard.
Is there a supported CLI command, API, or dashboard page for managing the lifetime of a specific preview URL? Do preview URLs expire automatically?
I am asking about retiring an individual preview without deleting the app, changing CMS data, or creating another deployment. Documentation or an example workflow would be appreciated. Thanks!
Unfortunately I have brought up this issue about a year ago - preview deployments stay up with no expiration, and are able to interact with the live database
This means if you ever made a preview deployment with vulnerable or volatile code, it is there and exposed forever
@noahlovell let this comment serve as a bump - the issue must be addressed…
This capability doesn’t exist yet. Dean’s right that preview URLs persist indefinitely with no documented way to revoke them.
The CLI docs confirm the behavior: “Each preview URL directs to a unique version of your project hosted on Wix’s servers. Subsequent updates to your project won’t affect any previously created versions.” The preview command has no flags for expiry, and there’s no dashboard control or API for managing preview lifecycles.
The security concern Dean mentioned is real. Preview deployments can interact with your live database, so a preview containing vulnerable code or exposed credentials stays accessible at its URL indefinitely.
Two paths forward:
Use wix release instead of wix preview for anything beyond quick internal testing. Release creates versioned deployments that you control through your project dashboard. You can unpublish versions, and they don’t persist as dangling URLs the way previews do. The tradeoff is that release registers your extensions and increments your version number, so it’s heavier than preview — but that’s the cost of lifecycle control.
For true previews with expiry, use a separate staging project with its own database. Clone your main project’s structure, point wix preview at the staging database, and tear down the staging project when you’re done. That kills all its preview URLs. More setup, but it works.
Feature request path: File this with Wix support as “preview URL lifecycle management” — ideally a --ttl flag on wix preview or a dashboard view of active preview URLs with a revoke button. Mention the security implication (exposed credentials in a preview), not just convenience. Dean’s tag of @noahlovell suggests it’s on someone’s radar, but there’s no timeline.
The immediate pragmatic answer: if you’ve already created previews with sensitive content, treat those URLs as compromised. Rotate any credentials that were in that code, audit what data those previews can reach, and use release going forward.
The release is a good solution for development, however, I do not remember there being an option to actually publish to the live site without creating a preview deployment, is there one?
As for on the radar, I don’t know if it is. I brought it up with Amanda back in October 2024 (and by the way, the preview deployment is still up since September 2024)
This is extremely problematic and should be top priority as a massive vulnerability.
Any error/vulnerability/security-leak patched from some version of any site is still fully available through the preview deployments, which still hold access to live CRM, users, billing, etc.
Previews MUST be:
Tracked - Currently if I do not save the links, I have no idea how many previews I deployed and how to reach them.
Expiring - With a default short period, and a certain max period. Never allow lifetime preview deployments.
Revoke-able - For immediate destruction of previews with discovered vulnerabilities
Optionally, also good:
4. max capacity for preview deployments
5. ability to create sandboxed databases so as not to interact with the live one through previews. And actually, reduce preview deployment access as a whole
6. Gate preview deployments with Wix site contributor authentication
I spoke with the team about this - and they agree that it’s important, and something they’re working towards.
In the meantime, if you identify a deployment that needs revoking, then you can reach out to Customer Care and the team will handle removing it for you until a self-serve option is available
