About 30 minutes to audit and move one reporting workflow
Vercel to BinHTML
Keep your applications on Vercel and move the generated HTML reports, dashboards, and review packets to artifact links that expire on their own.
Do not migrate if
Migrating has a cost and it is not always worth paying. If one of these describes your situation, stay where you are.
- The deployment is an application with routes, functions, or a framework build.
- You rely on preview deployments tied to branches and pull requests.
- The page is public, long-lived, and lives on a production domain.
Before you start
- A list of deployments that are really single generated documents.
- A BinHTML API key in your CI secret store.
- A decision on retention for each report type, since deployments do not expire and artifacts can.
Steps
01
Audit what is actually a report
Most teams find a handful of projects that exist purely to host a generated file: an eval dashboard, a weekly summary, a one-off analysis. Those are the migration candidates. Everything else stays.
02
Publish the report from the job that builds it
Replace the deploy step with a publish call. The response contains the share URL, so downstream steps can post it wherever the deployment URL used to go.
Publish from CI
Language: bash. Replace $BINHTML_API_KEY with a key from your settings.
# Reads report.html from disk, publishes it, prints the share URL. jq -n \ --arg title "Weekly report" \ --rawfile html ./report.html \ '{title: $title, visibility: "unlisted", sourceHtml: $html}' \ | curl -sS -X POST https://binhtml.com/api/v1/artifacts \ -H "Authorization: Bearer $BINHTML_API_KEY" \ -H "Content-Type: application/json" \ -d @- \ | jq -r '.urls.share'03
Keep one URL across runs
Store the artifact id after the first publish and post versions against it afterwards. This is the behaviour a deployment could not give you: a link that stays valid while the content changes.
Update in place
Language: bash. Replace $BINHTML_API_KEY with a key from your settings.
# Same artifact, new content. The share URL does not change. jq -n \ --arg label "$(date -u +%Y-%m-%d)" \ --rawfile html ./report.html \ '{label: $label, sourceHtml: $html}' \ | curl -sS -X POST "https://binhtml.com/api/v1/artifacts/$ARTIFACT_ID/versions" \ -H "Authorization: Bearer $BINHTML_API_KEY" \ -H "Content-Type: application/json" \ -d @-04
Set an expiry that matches the report
Reports tied to a pull request can expire quickly. Reports tied to a release should be permanent, which means Pro. Either way it is now a setting rather than a cleanup task.
05
Remove the retired projects
Delete the Vercel projects that only existed to serve a file. Your deployment list should describe applications you run, not reports you generated.
Verify the migration
Work through these before you remove anything from the old tool. A migration is finished when someone other than you has opened the new link successfully.
- Application deployments are untouched.
- The moved report renders identically and its link is posted where the deployment URL used to be.
- A second run updates the same artifact instead of creating another one.
Known gotchas
Framework output is not an artifact
If the report is produced by a framework build with routing and multiple output files, it is a site. Leave it deployed.
Analytics and headers do not come with it
Anything you configured at the deployment level, such as custom headers or analytics, does not transfer to an artifact link.
Questions about this migration
How do I migrate from Vercel to BinHTML?
Move only the report-shaped deployments, replacing each one with a publish call that returns a managed link.
How long does migrating from Vercel take?
About 30 minutes to audit and move one reporting workflow. The steps on this page cover creating an API key, publishing one document to confirm the output, switching repeat publishing to version updates, and verifying the result before you retire the old links.
When should I not migrate from Vercel?
The deployment is an application with routes, functions, or a framework build. You rely on preview deployments tied to branches and pull requests. The page is public, long-lived, and lives on a production domain.
Will the share link change when the content is updated?
No. Publishing a new version against an existing artifact id updates the content behind the same URL, so anyone already holding the link keeps working access.
Next steps
- API reference for every field and error code used above.
- Plan limits so a migration does not stall on a size or retention cap.
- All migration guides if more than one workflow is moving.
- Frequently asked questions for anything this guide did not cover.