A Vercel alternative for static output

Moving a site from Vercel

What your configuration maps to, what has no equivalent at all, and the order to do it in. The middle one is the part that decides whether this is an afternoon.

What maps to what

What has no equivalent

Handle these before you move DNS, not after. Pages serves files: it has an SPA fallback, custom error pages and an exclude list, and it has no redirect table and no custom response headers.

• Anything that executes. Route handlers, middleware, ISR, server components, api/ functions. If output: ’export’ does not produce a working site, that is the signal to stay rather than a problem to work around.
• rewrites, redirects and headers in vercel.json, apart from the SPA fallback. No redirect table and no custom headers exist here.
• cleanUrls and trailingSlash. We serve what your build produced, at the paths it produced. Set these in your framework so the output is already the shape you want.

The order to do it in

1. STEP 01

   Prove it builds to static output first

   Before anything else. For most frameworks this is the adapter or flag you already have; for Next.js it is output: ’export’. If this build fails, stop reading — your app needs a runtime and the honest answer is to stay on Vercel.
   next.js

   // next.config.js
   module.exports = { output: 'export' }

2. STEP 02

   Account for vercel.json

   List what it actually does. rewrites, redirects, headers, cleanUrls, trailingSlash — each one either becomes a build setting, becomes a real file in your output, or goes away. Only the catch-all rewrite has a direct equivalent, and it is --spa.

3. STEP 03

   Create the site and a CI token

   A site has to exist before anything can deploy to it — the action will not create one, so a typo fails instead of quietly publishing to a new address. Do both from the dashboard if you prefer.
   once

   $ one9x pages create mysite
   ✓ created mysite → https://mysite.one9x.app/
   $ one9x tokens create "github actions"
   one9x_tok_7Kd…  (shown once)

4. STEP 04

   Deploy the output directory and walk the routes

   Staging costs nothing and the preview is byte-identical to what would go live. Walk the routes here: a framework that was quietly relying on the platform shows up now rather than after the DNS change.
   first deploy

   $ one9x pages release ./out --site mysite
   ✓ v1 staged → https://v1--mysite.one9x.app/

5. STEP 05

   Swap the deploy step in CI

   If you deploy through Vercel’s Git integration, you are writing your first workflow — GitHub Actions has the whole file. If you already run a Vercel action, it comes out and this goes in, and you get the PR previews back with it.
   before

   - uses: amondnet/vercel-action@v25
     with:
       vercel-token: ${{ secrets.VERCEL_TOKEN }}
       vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
       vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
       vercel-args: '--prod'

   after

   - uses: one9x/pages-deploy@v1
     with:
       site: mysite
       dir: out
       token: ${{ secrets.ONE9X_TOKEN }}
       deploy: ${{ github.ref == 'refs/heads/main' }}
       comment: true

6. STEP 06

   Cut the domain over

   Lower the TTL a day ahead, link the domain here, publish the records we print, and let the certificate issue. Your Vercel deployment keeps serving until DNS actually moves, so there is no window where neither answers.

7. STEP 07

   Decommission

   Remove the project from Vercel once traffic has moved, and delete vercel.json from the repo so it is not mistaken for live config later.

Your live site on Vercel keeps serving throughout — nothing here touches it until you move DNS, and the free plan is enough to do the whole rehearsal first.