How to Migrate to Stormkit from Vercel or Netlify
Updated
Stormkit provides dedicated migration guides for both Vercel and Netlify, and the core migration path is the same: connect your Git repository (GitHub, GitLab, or BitBucket), let Stormkit build and deploy on push, then point your domain at the new deployment. You can start on Stormkit Cloud or self-host the platform on your own infrastructure. The steps below assume you already have a working app on Vercel or Netlify and a Git repository you control.
What carries over and what changes
Stormkit is positioned as a self-hostable alternative to Vercel and Netlify, so the mental model is similar: repository-linked deployments, preview environments, and automatic TLS. The difference is where the build and runtime live — you can keep them on Stormkit Cloud or run the whole platform on your own servers.
| Concern | Vercel / Netlify | Stormkit |
|---|---|---|
| Deploy trigger | Git push | Git push to deploy |
| Repo hosts | GitHub, GitLab, Bitbucket | GitHub, GitLab, BitBucket |
| Preview URLs | Per-deployment URLs | Unique URLs for each deployment |
| TLS | Managed automatically | Automatic TLS, plus custom TLS certificates |
| Rollback | Redeploy previous build | Instant rollbacks |
| Hosting location | Vendor cloud | Stormkit Cloud or your own infrastructure (on-premises or cloud) |
| Platform features | Varies by plan | Managed database, authentication, transactional email, cron jobs, analytics |
Because Stormkit also ships managed database, authentication, transactional email, cron jobs, and analytics, some things you currently wire up through separate services on Vercel or Netlify may be available inside the platform. Check the migration guide for your specific source platform before assuming a one-to-one mapping.
Migration steps
1. Read the platform-specific migration guide
Stormkit publishes separate migration guides for Vercel and Netlify. Start there, because build commands, output directories, and environment variable handling differ between the two source platforms and the guide will tell you what to change rather than what to keep.
2. Choose Cloud or self-hosted
- Stormkit Cloud: fastest path; sign in and connect a repository.
- Self-hosted: run Stormkit on your own infrastructure. The documented install is a single command:
curl -sSL https://www.stormkit.io/install.sh | sh
The installer is interactive — you pick the domain and settings as you go. This is the option to choose if keeping infrastructure and data under your own control is the reason you are migrating.
3. Connect your repository
Link your GitHub, GitLab, or BitBucket repository. This is the step that turns on automated deployments — from here, pushing to your repository triggers a deploy.
4. Configure the build for your framework
Use Stormkit's deployment guides as the reference for your stack. The site lists guides for Strapi CMS, Remix, self-hosting on Hetzner, and Cloud Run, plus a local development guide. If your app runs locally the same way it does in production, the local development guide is the quickest way to confirm your build settings before you push.
5. Verify the first deployment
After the first push, confirm:
- The deployment succeeded and you have a unique URL for that deployment.
- TLS is active on the generated URL.
- Your app's runtime behavior matches what you saw on Vercel or Netlify — check API routes, environment variables, and any server-side rendering.
6. Move your domain and TLS
Add your custom domain in Stormkit. Automatic TLS is provided, and you can also upload your own custom TLS certificates if you need them. Keep the old platform live until DNS has fully propagated and you have confirmed the new deployment serves correctly.
7. Set up the operational pieces
- Instant rollbacks: confirm you can roll back to a previous deployment before you cut over traffic.
- Zero downtime rolling updates: Stormkit deploys updates without interrupting users, so you do not need a maintenance window for subsequent releases.
- Monitoring: performance, errors, and user analytics are available in real time.
- Automated E2E testing: you can run automated scripts after deployments, which is useful for catching migration regressions.
- Audit logs: track team changes if more than one person deploys.
Common migration snags
- Build output mismatch. Vercel and Netlify each have their own conventions for output directories and build commands. Use the migration guide rather than copying settings across.
- Environment variables. Re-enter them in Stormkit; do not assume they transfer.
- Serverless vs. long-running processes. Stormkit runs full applications, so code that assumed a serverless execution model may need adjustment — and code that needed workarounds on Vercel or Netlify may get simpler.
- DNS cutover timing. Because rollbacks are instant, the risk is low, but keep the old deployment reachable until the new domain resolves correctly everywhere.
- Self-hosting prerequisites. The install script handles setup interactively, but you still need a server and a domain you control.
When migrating makes sense
Migrating to Stormkit is worth the effort if you want to own your infrastructure and data, want the platform services (database, auth, email, cron, analytics) in one place, or are hitting cost or deployment-time problems on your current platform. One cited case study reports deployment times dropping from 24+ hours to 7 minutes and infrastructure costs falling 60% after moving to Stormkit — treat that as a single data point from one team, not a guarantee.
If you are happy with Vercel or Netlify and do not need self-hosting or the bundled platform services, there is no forcing reason to move. The migration guides exist so the switch is a configuration exercise rather than a rewrite, but the decision still comes down to whether owning the infrastructure matters to you.