Understand PreviewShip plans before you hit a limit
Understand project limits, deploy quotas, upload allowances, password access, rollback history, watermark removal, preview expiry windows, and which plan fits each workflow.
Answer First
PreviewShip plans are designed around preview-sharing workflows rather than production traffic. The main limits to care about are projects, deploy frequency, upload allowance, concurrent builds, preview expiry time, watermark removal, password access, and how many rollback-capable versions you can keep visible behind each fixed project URL. Free keeps one project and three retained versions; Pro adds more projects, more deployment volume, password access, longer retention, and larger rollback history.
Deploy build artifacts, not source-code zips.
If you upload a zip, build the project first and zip the static output folder such as dist, build, out, or public with index.html and assets. Do not zip raw React/Vue/Next source folders with package.json and node_modules. Single .html, .md/.markdown, and .pdf files are supported directly by console upload, CLI, MCP, and the VS Code/Cursor extension.
Key takeaways
Comparison snapshot
How to choose a plan
Choose based on how often your team needs to generate previews. Teams reviewing multiple iterations per day usually feel daily and monthly deploy limits before they feel project caps.
If previews need to stay available for client review over weeks or months, expiry time matters just as much as quota. If you need share links without the PreviewShip watermark, password-protected access, or more rollback history behind the same fixed project URL, choose a Pro plan.
What the limits are really protecting
PreviewShip is optimized for fast artifact upload and quick sharing, so the limits mostly shape burst usage and storage retention rather than classic bandwidth-heavy production hosting concerns.
What Free users can do when the project limit is full
Free accounts keep one project. When that project slot is full, the user can either upgrade or delete an unused project before deploying or claiming another preview.
Deletion is intentionally explicit because it removes the fixed preview URL, hosted project, deployment association, and Showcase item permanently. The same rule should appear in console limit errors, pricing copy, FAQ, CLI/MCP docs, and support material.
How Pro access and rollback fit together
Password access is a project-level Pro capability. It protects the fixed project link while keeping repeat deploys and rollback behavior centered on the same URL.
Rollback queues a new deployment from a retained historical version when its artifact is still available. The fixed project link switches only after that deployment succeeds.
FAQ
What usually pushes teams from free to paid?
Most teams upgrade when they need watermark-free preview links, password access, more deploys per day, more active projects, longer preview retention, or more rollback history for review cycles.
Do limits affect manual upload and CLI deploys differently?
No. Limits apply to the account workflow regardless of whether the preview was created from browser upload, editor, CLI, or MCP.
Why is preview expiry part of pricing?
Retention affects how long PreviewShip keeps preview artifacts and links available, which changes the cost profile for the service.
Can I switch a password-protected project back to public?
Yes. Public access clears the project password. Public projects can be shared normally and may become eligible for Showcase and sitemap indexing when the user chooses to share them.
How many versions can I roll back to?
Free shows the most recent 3 retained versions, Pro Monthly shows 10, and Pro Yearly shows 40. If an artifact has already been cleaned up, the version can remain visible as history but cannot be rolled back.
Can deleting a project help when the Free limit is full?
Yes. Deleting an unused project frees the Free project slot, but it permanently removes the fixed preview link, hosted project, deployment association, and Showcase entry.