Webflow Exporter logo
ResourcesContact
All resources

Self-Hosted Webflow Staging: Preview Without the Staging Plan

Webflow gives you exactly one staging environment: <sitename>.webflow.io. It works for “does this design look right,” but it falls apart the moment you need real preview infrastructure — multiple stakeholder branches, a stable preview URL on your domain, an environment that survives Site plan downgrades, or a place to test integrations against the production database.

This post is the staging workflow we've seen teams settle on: export from Webflow on a schedule, deploy to a real preview URL, get the multi-environment story without paying for the multi-environment plan.

Why Webflow's built-in staging stops being enough

Three specific things break down on the webflow.io preview:

  1. One preview per site. No branches, no per-PR previews. If two people want to test different in-progress changes, they have to coordinate manually.
  2. No custom domain on the preview. You can't share staging.yoursite.com — only <sitename>.webflow.io. Some tools (OAuth callbacks, third-party integrations, asset CDNs configured for your domain) genuinely require a controlled domain to test against.
  3. Tied to your live Designer. The preview reflects what's in the Designer right now. There's no way to keep an “approved” staging state stable while you continue editing.

For solo marketers, none of this matters. For any team beyond two people who ship together, it's a recurring source of friction.

The pattern: export-driven staging

The setup, before details:

  1. Webflow stays the editor. Marketing publishes changes the way they already do.
  2. A scheduled job exports the published Webflow site to static files.
  3. Those static files deploy to a preview URL (staging.yourdomain.com).
  4. Production is a separate deploy, behind a manual approval step.

This decouples “Webflow is live” from “production users see it.” The handoff becomes “publish in Webflow → wait for staging build → review at staging.yourdomain.com → promote to production.”

A concrete implementation, end to end

Pick the host based on your team's habits. We'll use Vercel here because it has good multi-env support, but Cloudflare Pages and Netlify work the same way. The mechanism is:

Step 1: Get a Webflow API token

In Webflow: Site settings → Apps & Integrations → API access → Generate. Read-only scopes are enough. Store it as a secret in your CI environment, not in code.

Step 2: Wire the export to CI

Create a small CI job (GitHub Actions in this example) that runs on a schedule:

# .github/workflows/staging.yml
name: Refresh Webflow staging

on:
  schedule:
    - cron: "*/30 * * * *"   # every 30 minutes
  workflow_dispatch:

jobs:
  export-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Webflow Export
        run: |
          curl -X POST https://webflowexport.com/api/exports \
            -H "Authorization: Bearer $WEBFLOW_EXPORT_TOKEN" \
            -d '{ "webflowToken": "${{ secrets.WEBFLOW_API_TOKEN }}", "siteId": "${{ vars.WEBFLOW_SITE_ID }}" }' \
            -o export.zip

      - run: unzip export.zip -d ./out

      - name: Deploy to Vercel preview
        run: |
          npx vercel deploy ./out \
            --prod=false \
            --token=${{ secrets.VERCEL_TOKEN }} \
            --scope=${{ vars.VERCEL_ORG }} \
            --name=staging-yourdomain

The schedule (*/30) gives you a fresh staging environment every 30 minutes after marketing publishes. Adjust based on how often the content changes.

Step 3: Stable staging URL on your domain

In Vercel: configure staging.yourdomain.com to alias the latest preview build of the staging-yourdomain project. (Cloudflare Pages and Netlify both have equivalent “branch alias” mechanisms.)

This is the URL the team uses for review. It's on your domain, has its own TLS cert, and lives separately from production.

Step 4: Promote to production explicitly

Production gets a separate deploy with a manual approval gate:

# .github/workflows/promote.yml
name: Promote to production

on:
  workflow_dispatch:    # manual trigger only

jobs:
  promote:
    environment: production    # requires an approver in GitHub Settings
    runs-on: ubuntu-latest
    steps:
      - name: Use the latest staging export
        run: |
          # fetch the last successful staging deploy artifact
          # ... or re-export and deploy directly
          npx vercel deploy ./out \
            --prod=true \
            --token=${{ secrets.VERCEL_TOKEN }} \
            --scope=${{ vars.VERCEL_ORG }} \
            --name=production-yourdomain

Now publishing in Webflow doesn't mean users see it. Marketing publishes → 30 minutes later staging updates → reviewer approves → production deploys.

Three variations worth considering

The setup above is the simple one. Three real-world variations we've seen:

Per-PR previews via GitHub PRs

If your team works in PRs even for content, the workflow can run on pull_request events and produce per-PR preview URLs. Useful for “here's the landing page redesign for review” flows where the PR holds custom code and a Webflow snapshot.

Webhook-triggered staging

Instead of polling on a schedule, configure a Webflow webhook to fire on publish. The CI workflow runs immediately. Lower latency (5 minutes instead of 30), more wiring.

Snapshot-locked staging

Sometimes you want staging to not track Webflow live — e.g. when leadership approves a state and you don't want subsequent Webflow edits to pollute the staging environment. Solution: archive the export ZIP in S3 with a Git-style tag, and have the staging deploy pin to that ZIP until explicitly unpinned.

Cost story

For a typical setup:

ComponentCost
Webflow workspace (free Starter)$0
Vercel Hobby (non-commercial) or Pro$0 / $20 per seat
Webflow Export (re-export window)$0 for 30 days per export
GitHub Actions (2,000 min/mo free)Usually $0

For commercial sites: switch Vercel to Pro and budget ~$30/mo total. Compared to Webflow's own multi-staging features on the higher plans, this is dramatically cheaper at the same or better functionality.

When it's not worth the trouble

A few honest cases where the export-driven staging pattern is overkill:

  • Solo creator, weekly publishing. Webflow's default webflow.io preview is fine; the wiring above is more than the problem.
  • Team that never deviates from “publish in Webflow == ship to users.” No staging discipline = no benefit from staging infrastructure.
  • Very low traffic site where production downtime is fine. The whole point is reducing “published wrong thing on prod” risk; if that risk is low, save the engineering time.

If two of those three describe you, skip this and just publish in Webflow.

The minimum viable version

If the full CI flow feels heavy, the cheap version that captures 80% of the value:

  1. Once a week, manually export the site.
  2. Drag the export folder onto app.netlify.com/drop.
  3. Share the unique Netlify URL with the team for review.

That's genuinely useful even without automation. It gives you the “published state was approved at a specific moment” property that Webflow alone doesn't. Automate later when the manual cadence becomes the bottleneck.

For the longer story on hosting the result, where to host an exported Webflow site covers the per-host tradeoffs. For the deploy-to-Vercel specifics, host an exported Webflow site on Vercel walks through the same workflow at single-environment depth.