If your Netlify site is mostly static (Vite, Astro, Hugo, MkDocs, static-export sites, etc.), the migration is straightforward, because VibeHost reads Netlify-style _redirects files.

Steps

1. Check the local build

Run whatever Netlify is configured to run (npm run build, hugo, etc.). If it produces a static directory locally, you're set.

2. Create the VibeHost app

vibehost app create my-site
vibehost link --app my-site

3. Deploy for the first time

Find the publish directory Netlify uses. It's in netlify.toml under [build] publish = "...", and is typically dist/, _site/, public/, or out/:

vibehost deploy ./dist

If your site uses client-side routing (Vue Router, React Router with browser history, SvelteKit SPA):

vibehost deploy ./dist --spa

Netlify's _redirects file carries over if you put it at the root of your publish directory. Rewriting it as vibehost.json is better, since _redirects is deprecated. _headers is ignored, and VibeHost does not support custom response headers, so before moving confirm your site does not depend on them (CSP, CORS, and so on).

# _redirects
/old-page    /new-page    301
/blog/*      /posts/:splat 301

The VibeHost dispatcher reads these on deploy. For redirects you can change without a rebuild, use platform redirects:

vibehost redirects add /old /new --app my-site
vibehost redirects list --app my-site

Platform redirects override _redirects on conflict.

5. Forms, Functions, and Edge Functions

These are Netlify-specific and don't have direct VibeHost equivalents today:

Replace Netlify Forms with an external form backend (Formspree, Web3Forms, Basin, your own API).
Host what ran as Netlify Functions (Lambda) on a managed service (Fly.io, Render, Railway, your own API host), and call it from the static frontend on VibeHost.
Treat Edge Functions the same way. Keep the static site on VibeHost and move the edge logic to a dedicated edge provider until VibeHost's server runtime ships publicly.

If your site is mostly forms and functions, put the frontend on VibeHost and the backend wherever it fits best. Server-side rendering on VibeHost is in private beta. See the Next.js guide for status.

6. Environment variables

List your existing vars in Netlify (if you have netlify-cli), then set them on VibeHost:

netlify env:list
vibehost env set DATABASE_URL=... --app my-site --target runtime
vibehost env set API_KEY=... --app my-site --secret

On static apps, env vars reach only _redirects substitution and a few specific build-time placeholders. Most build-time env vars belong in your CI or local shell before npm run build, not in vibehost env set.

7. Custom domain

vibehost domain add www.example.com --app my-site
vibehost domain verify www.example.com --app my-site

At your DNS provider, swap the CNAME from <site>.netlify.app to <app>.vibehost.space. See custom domains for per-provider walkthroughs.

8. Cutover

After the DNS swap, traffic moves over gradually as caches expire, typically within 5 minutes to an hour with a 300s TTL. Netlify and VibeHost both serve during the transition. Deactivate Netlify only after 24 hours without problems.

Feature parity table

Netlify feature	VibeHost equivalent	Notes
Static deploys	Yes	Identical model
Build minutes	n/a	Build on your machine / CI
`_redirects`	Yes	Same syntax
`_headers`	No	Ignored; custom response headers are not supported
Custom domains + HTTPS	Yes	Automatic HTTPS, no config
Deploy previews	Yes	channels, not branch-tied
Branch deploys	Yes	Channels with branch names work fine
Forms	No	External form backend
Functions	No	Host backend externally (server runtime in private beta)
Edge Functions	No	Host edge logic externally for now
Identity / auth	No	External auth (Clerk, Auth.js, Supabase)
Large Media	No	Use S3 / external object storage
Split testing	No	Roll your own client-side or external edge
Bandwidth limits	Different	See pricing

What changes for your team

Deploys are a CLI command, not a git push. Set up CI/CD with GitHub Actions if you want to keep deploying on push.
There are no build minutes. On Netlify you paid for compute on their builders. Your build runs on your own hardware or CI runners, and runners on GitHub or GitLab are typically free for open source and cheap for teams.
Per-PR previews still exist. See the PR previews recipe.
Form data goes elsewhere. Pick a backend before the cutover.

Rollback plan

Rolling back at the DNS level, by pointing the record at Netlify again, is the safest option. Keep the Netlify site live for at least 7 days after the cutover, and delete the Netlify project only once you're confident.

Move from Netlify to VibeHost