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

  1. 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.

  2. 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'
  3. 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 @-
  4. 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.

  5. 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