Forem: Savas Vedova

How We Migrated from AWS to Hetzner Without Downtime

Savas Vedova — Fri, 30 Jan 2026 08:58:41 +0000

Before we get started, Stormkit is an open-source, boostrapped, self-hostable Vercel alternative that is operating in the EU. It allows building, deploying and hosting websites.

Recently, we completed a full infrastructure migration from AWS to Hetzner. Zero downtime. Production websites kept humming. Users didn't notice a thing. Here's how we pulled it off—and the rabbit holes we fell into along the way 🐇

Why Hetzner?

Let's address the elephant in the room: AWS is expensive. For a bootstrapped company like ours, cutting infrastructure costs by 60-70% while maintaining (or improving) performance is a no-brainer. Hetzner offers bare-metal-like performance at a fraction of the cost, and their European data centers aligned perfectly with our user base.

But migrating isn't just about spinning up new servers. We had to move databases, redirect traffic from existing AWS IPs, and keep everything running while we did it. No pressure.

The Migration Checklist

Before diving in, here's what we were dealing with:

PostgreSQL database with production data that couldn't afford a single lost transaction
Multiple domains pointing to AWS Elastic IPs
Serverless functions (Lambda) that don't have a Hetzner equivalent
Production websites serving real users 24/7

Let's tackle each one.

Database Migration: The Scary Part

Database migrations are where things can go spectacularly wrong. One missed transaction, one replication lag spike, and you've got angry users and corrupted data. We needed a zero-downtime approach.

The Strategy: Logical Replication

PostgreSQL's logical replication was our friend here. The plan:

Set up a fresh PostgreSQL instance on Hetzner
Configure logical replication from AWS RDS to Hetzner
Let it sync while production continues on AWS
Switch over when replication is caught up

-- On the source (AWS RDS), create a publication
CREATE PUBLICATION stormkit_pub FOR ALL TABLES;

-- On the target (Hetzner), create a subscription
CREATE SUBSCRIPTION stormkit_sub
  CONNECTION 'host=aws-rds-endpoint dbname=stormkit user=replicator password=xxx'
  PUBLICATION stormkit_pub;

The beauty of logical replication is that it keeps both databases in sync in near real-time. We monitored the replication lag obsessively:

SELECT * FROM pg_stat_subscription;

When lag hit zero consistently, we were ready to switch. The actual cutover was anticlimactic—update the connection string, restart the app, done. Total write downtime: ~2 seconds while the app restarted.

The AWS IP Problem

Here's where things got spicy 🌶️

We had multiple Elastic IPs on AWS that customers had configured in their DNS. Changing DNS records takes time to propagate (thanks, TTL), and we couldn't ask customers to update their records on a schedule. We needed those AWS IPs to keep working but forward traffic to Hetzner.

Enter: The EC2 NAT Gateway

The solution was surprisingly simple in concept but devilishly complex in execution: keep an EC2 instance on AWS purely to forward traffic to Hetzner.

Client → AWS Elastic IP → EC2 (NAT) → Hetzner Load Balancer → Hetzner Server

Easy, right? Just some iptables rules:

# Forward incoming traffic to Hetzner
iptables -t nat -A PREROUTING -i enX0 -p tcp --dport 443 -j DNAT --to-destination HETZNER_LB_IP:443
iptables -t nat -A PREROUTING -i enX0 -p tcp --dport 80 -j DNAT --to-destination HETZNER_LB_IP:80

# SNAT for return traffic
iptables -t nat -A POSTROUTING -d HETZNER_LB_IP -j MASQUERADE

Ship it! ✅

Except... we had two Elastic IPs. Which meant two ENIs (Elastic Network Interfaces). Which meant... asymmetric routing hell.

The Multi-ENI Nightmare

When you have multiple ENIs on an EC2 instance, traffic can come in on one interface and try to leave on another. This breaks TCP connections because the source IP doesn't match what the client expects.

Here's what we saw in conntrack:

src=CLIENT_IP dst=172.31.25.182 sport=39132 dport=443
src=HETZNER_LB_IP dst=172.31.31.236 sport=443 dport=39132

Traffic came in on ENI #2 (172.31.25.182) but responses were trying to go out via ENI #1 (172.31.31.236). The client would never receive the response.

The Fix: Policy-Based Routing + Packet Marking

We needed to ensure symmetric routing—packets that come in on interface X must go out on interface X. Here's the solution:

1. Create routing tables for each ENI:

echo "100 enX0_table" >> /etc/iproute2/rt_tables
echo "101 enX1_table" >> /etc/iproute2/rt_tables

ip route add default via 172.31.16.1 dev enX0 table enX0_table
ip route add default via 172.31.16.1 dev enX1 table enX1_table

ip rule add from 172.31.31.236 table enX0_table
ip rule add from 172.31.25.182 table enX1_table

2. Mark packets based on incoming interface:

iptables -t mangle -A PREROUTING -i enX0 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i enX1 -j MARK --set-mark 2

3. SNAT based on the mark:

iptables -t nat -A POSTROUTING -m mark --mark 1 -d HETZNER_LB_IP -j SNAT --to-source 172.31.31.236
iptables -t nat -A POSTROUTING -m mark --mark 2 -d HETZNER_LB_IP -j SNAT --to-source 172.31.25.182

4. Disable reverse path filtering (crucial!):

sysctl -w net.ipv4.conf.all.rp_filter=0

5. Disable source/destination checks on AWS:

In the AWS console, we also had to disable source/destination checks for both the EC2 instance and each ENI. By default, AWS drops packets if the source or destination IP doesn't match the instance's assigned IP—which breaks NAT. Go to EC2 → Network Interfaces → Actions → Change Source/Dest Check → Disable.

After hours of tcpdump, conntrack debugging, and hair-pulling, HTTPS finally worked through both IPs. The feeling when curl https://your-domain.com returns a 200 after all that? Chef's kiss 👨‍🍳

The Serverless Dilemma

Hetzner doesn't have Lambda. No FaaS offering. Nada.

For Stormkit, serverless functions are a core feature. Users deploy functions, and they need to run somewhere. We had three options:

Build our own FaaS platform on Hetzner (way too complex)
Migrate to a different serverless provider
Keep Lambda on AWS and route function traffic there

We chose option 3. It's pragmatic—Lambda works, it's battle-tested, and rewriting our entire function runtime wasn't worth the engineering effort. Sometimes the boring solution is the right one.

The architecture now looks like:

┌─────────────────┐     ┌─────────────────┐
│   Hetzner LB    │────▶│  Hetzner Apps   │
└─────────────────┘     └─────────────────┘
         │
         ▼ (function requests)
┌─────────────────┐
│   AWS Lambda    │
└─────────────────┘

This hybrid approach lets us benefit from Hetzner's pricing for the heavy lifting while keeping Lambda for what it does best.

Production Website Migration

The final piece: moving actual user traffic without anyone noticing.

Our strategy was gradual:

Deploy the app on Hetzner and run it in parallel with AWS
Use health checks to ensure Hetzner was serving correctly
Update the load balancer to send traffic to Hetzner
Monitor aggressively for the first 24 hours

Having AWS as a backup meant we could instantly rollback if something went wrong. Spoiler: we didn't need to.

Lessons Learned

Test NAT gateways from outside, not localhost. We spent hours debugging HTTPS issues that only existed because we were testing from the EC2 itself. Packets were bypassing PREROUTING entirely.
Multi-ENI routing is hard. If you're doing anything with multiple network interfaces, budget extra time for debugging. tcpdump and conntrack are your best friends.
Logical replication is magic. PostgreSQL's replication made database migration almost boring (in a good way).
Hybrid cloud is fine. You don't have to migrate everything. Keeping Lambda on AWS while running compute on Hetzner is a perfectly valid architecture.
Have a rollback plan. Every step of the way, we knew exactly how to undo what we'd done. That confidence made us move faster.

Wrapping Up

Cloud migrations are intimidating, but they don't have to be catastrophic. With the right planning, the right tools, and a healthy dose of paranoia, you can move mountains of infrastructure without dropping a single request.

If you're considering a similar migration, feel free to reach out. We've got the battle scars and the iptables rules to prove we survived 💪

We’ve just simplified Stormkit’s pricing 🚀 All limits scale linearly with seats — buy 10 seats, get 10 the resources. No hidden fees, no surprises. A huge thank you to everyone who gave feedback on the old model.

Savas Vedova — Fri, 05 Dec 2025 13:13:10 +0000

Stormkit v1.25.0 is out 🚀 New feature: User sign-up management. Admins can now enable/disable new sign-ups or set approval mode to moderate registrations. Read more: https://www.stormkit.io/docs/self-hosting/managing-users

Savas Vedova — Wed, 03 Dec 2025 14:46:34 +0000

Self-Hosting with Stormkit: User Management" - Stormkit

Learn how to manage user access to your self-hosted Stormkit instance. Configure sign-up modes, whitelist domains, and approve or reject user registrations.

stormkit.io

We’ve officially merged www-stormkit-io stormkit-io 🎉 All code, deployment logic, and (most importantly) the docs now live in a single repository. No more jumping between two repos: simpler maintenance, faster iterations, happier team.

Savas Vedova — Fri, 28 Nov 2025 08:33:28 +0000

Stormkit v1.24.0 is out 🚀 Lot's of small improvements, documentation updates, feature enhancements and windows support. https://github.com/stormkit-io/stormkit-io/blob/main/CHANGELOG.md

Savas Vedova — Fri, 21 Nov 2025 16:54:04 +0000

stormkit-io/CHANGELOG.md at main · stormkit-io/stormkit-io · GitHub

Self-hostable alternative to Vercel/Netlify. Deploy modern web apps with automated CI/CD, custom domains, and environment management. - stormkit-io/stormkit-io

github.com

I believe even small achievements deserve a proper celebration. Just a few days after announcing that Stormkit is now fully open-source, we’ve crossed 100 stars and contributions are already pouring in from brilliant minds 😍

Savas Vedova — Mon, 10 Nov 2025 08:38:50 +0000

Big news 🚀 Stormkit is now fully open source! This has been my dream for so long, and now it came true! Here's the repo: https://github.com/stormkit-io/stormkit-io Let's build together!

Savas Vedova — Tue, 04 Nov 2025 06:35:43 +0000

GitHub - stormkit-io/stormkit-io: Self-hostable alternative to Vercel/Netlify. Deploy modern web apps with automated CI/CD, custom domains, and environment management. · GitHub

Self-hostable alternative to Vercel/Netlify. Deploy modern web apps with automated CI/CD, custom domains, and environment management. - stormkit-io/stormkit-io

github.com

Docker Port Publishing: A Security Wake-Up Call 🚨

Savas Vedova — Fri, 19 Sep 2025 11:55:56 +0000

Did you know that ports: "5432:5432" in your docker-compose.yml is exposing your database to the entire internet?

I see this mistake constantly in production environments. Here's what's actually happening:

❌ What you think you're doing:

services:
  postgres:
    image: postgres:15
    ports:
      - "5432:5432"  # "Just making it accessible to my app"

🌍 What you're actually doing:

Binding port 5432 to 0.0.0.0:5432 - making your database accessible from ANY IP address that can reach your server.

✅ Here's how to fix it:

Option 1: Bind to localhost only

ports:
  - "127.0.0.1:5432:5432"  # Only accessible from the host machine

Option 2: Use Docker networks (recommended)

# No ports section needed!
services:
  postgres:
    image: postgres:15
    networks:
      - app-network

  web:
    image: my-app
    networks:
      - app-network
    ports:
      - "80:3000"  # Only expose what users need

networks:
  app-network:

🔐 Pro tip: Your application containers can communicate with each other using service names as hostnames within the same network. No port publishing required!

The golden rule: Only publish ports that external clients need to access directly.

Have you caught this security issue in your own Docker setups? Share your Docker security tips in the comments! 👇

Node.js Hosting: DIY Flexibility vs. Stormkit’s Streamlined Power

Savas Vedova — Thu, 24 Jul 2025 13:51:54 +0000

When it comes to hosting Node.js applications, you’re faced with a choice: build and manage your own infrastructure or use an orchestrator like Stormkit, purpose-built to scale and simplify, especially for managing multiple apps or hundreds of long-lived processes. While DIY hosting offers control, Stormkit’s feature set makes it a compelling choice for developers looking to optimize resources and streamline workflows.

Let’s break down the trade-offs, highlighting Stormkit’s unique strengths and acknowledging the realities of self-hosting.

DIY Hosting: Control at a Cost

Running your own Node.js setup, with a process manager like PM2, or systemd, gives you full control over your environment. For small projects or developers who enjoy fine-tuning servers, this can be a great fit. But as you scale to multiple apps or hundreds of processes, the DIY approach shows its limits.

Scaling Complexity: Managing traffic spikes across multiple apps means manually provisioning servers, setting up load balancers, and ensuring uptime. This can lead to over-provisioning, where you’re paying for idle servers, or under-provisioning, risking crashes during surges.
Maintenance Burden: You’re responsible for server updates, Node version upgrades, and monitoring resource usage. Juggling multiple apps amplifies this, as each may have different runtime or dependency needs, leading to configuration sprawl.
Security Overhead: Securing multiple apps requires configuring firewalls, SSL certificates, and staying vigilant about vulnerabilities. A single misstep can expose your apps, and keeping everything patched is a time sink.
Deployment Friction: Rolling out updates across multiple apps often involves manual restarts, risking downtime. Testing new versions or rolling back failed deployments can be clunky without a streamlined system.
Cost Inefficiency: A small VPS is cheap, but scaling multiple apps across servers, plus adding redundancy and monitoring, drives up costs. Your time spent managing servers is another hidden expense.

DIY hosting is ideal for small, single-app projects or when you need highly specific configurations. If you’ve got the skills and time, it’s a hands-on way to learn and save on small-scale costs. But for managing multiple Node.js apps at scale, the overhead can pull you away from coding.

Stormkit: Optimized for Scale and Simplicity

Stormkit is designed to handle Node.js applications at scale, especially when you’re managing multiple apps or long-lived processes. Its feature set addresses the pain points of DIY hosting, though self-hosting Stormkit means you still manage the underlying servers. Here’s why Stormkit stands out:

Resource-Efficient Orchestration: Stormkit’s on-demand spin-up and spin-down mechanism optimizes server usage. Instead of running multiple machines for each app, Stormkit orchestrates processes across fewer instances, dynamically allocating resources. What might take many servers in a traditional setup can often be handled with just a few, saving costs and reducing waste.
Insightful Analytics: Stormkit provides a dashboard with stats on your most-visited and most-deployed apps. This quick overview helps you prioritize optimization and understand usage patterns, something DIY setups require custom tooling to achieve.
Flexible Runtime Management: With Stormkit, you can manage Node runtimes via a .node-version file, supporting multiple versions across apps. This eliminates the hassle of manually installing and switching runtimes on servers, a common DIY headache.
Seamless Deployments: Deploying with Stormkit is as simple as a git push, with zero-downtime updates and instant rollbacks if something goes wrong. Each deployment gets a unique URL for testing, and you can add an auth wall to secure preview environments—features that require significant DIY effort to replicate.
Self-Hosting Maintenance: Since Stormkit is self-hosted, you’re responsible for maintaining the servers it runs on—patching the OS, monitoring hardware, and ensuring uptime. While Stormkit handles app-level orchestration, the server-level maintenance remains your responsibility.

The Takeaway: Match Your Needs

DIY hosting offers unparalleled control and is great for small projects or developers who love hands-on server work. It’s cost-effective for single apps and lets you tailor every detail, but scaling multiple apps or processes can lead to complexity, inefficiency, and maintenance overload.

Stormkit flips this by streamlining orchestration, deployments, and runtime management, letting you achieve more with fewer servers. Its analytics, unique deployment URLs, and auth walls make managing multiple apps a breeze, though you’ll still need to handle server maintenance for self-hosting. If you’re focused on coding and scaling efficiently, Stormkit’s purpose-built features are a game-changer. If you have unique server needs or like to be hands-on, DIY might still be your path.

Either way, keep your focus on building great apps 🚀

How to Run Automated E2E Tests with Stormkit and Browserless

Savas Vedova — Mon, 14 Jul 2025 12:17:46 +0000

Running automated browser tests is crucial for maintaining application quality, but managing browser instances can be resource-intensive. This tutorial shows you how to set up scalable automated testing using Stormkit's self-hosted solution with Browserless for efficient browser management.

What You'll Build

By the end of this tutorial, you'll have:

A self-hosted Stormkit instance with Browserless integration
Automated Playwright tests running in a scalable browser environment
Continuous testing on every deployment

Prerequisites

A Virtual Private Server with SSH access
Basic knowledge of React and Node.js
Familiarity with Playwright testing framework

Step 1: Setting Up Stormkit

First, let's install Stormkit using the single-liner installation script:

curl -sSL https://www.stormkit.io/install.sh | sh

This script will set up the basic Stormkit infrastructure on your server.

Step 2: Configure Docker Compose with Browserless

Next, we need to update the docker-compose.yaml file that comes with Stormkit installation, to include Browserless alongside Stormkit. This provides us with a scalable browser environment for our tests.

services:
  # ... db, redis, workerserver, hosting services

  browserless:
    image: ghcr.io/browserless/chromium
    restart: always
    ports:
      - published: 3000
        target: 3000

Start your services:

docker compose up -d

Step 3: Set Up the React Application

Now let's create our React application locally to test our setup.

We can use the react-starter example for this tutorial.

git clone https://github.com/stormkit-io/react-starter.git
cd react-starter
npm install

Install Playwright Core

Since we're using Browserless for browser management, we only need the core Playwright library without the full testing framework. We will also need tsx to run Typescript code:

npm install playwright-core tsx --save-dev

Step 4: Create Your Playwright Tests

Create a tests directory and add your test files:

mkdir tests

Create a basic test file tests/app.spec.ts:

import { chromium } from 'playwright-core'

const test = async () => {
  // Connect to the remote browser via Browserless
  const browser = await chromium.connect(
    process.env.PLAYWRIGHT_WS_ENDPOINT ||
      'ws://localhost:3000/chromium/playwright'
  )

  const context = await browser.newContext()
  const page = await context.newPage()
  const host = process.env.SK_DEPLOYMENT_URL || 'http://localhost:5173'
  const url = `${host}/ssr`

  try {
    // Navigate to your application
    const response = await page.goto(url)

    // Test your application
    await page.waitForSelector('.list')
    const title = await page.textContent('h1')
    console.log('Page title:', title)

    if (!response) {
      throw new Error('Failed to fetch API health endpoint')
    }

    console.log('API health status:', response.status())
    console.log('✅ All tests passed!')
  } catch (error) {
    console.error('❌ Test failed:', error.message)
    throw error
  } finally {
    await context.close()
    await browser.close()
  }
}

// Run the test
;(async () => {
  try {
    await test()
  } catch (e) {
    console.error(e)
    process.exit(1) // This is important as it tells Stormkit that the process failed
  }
})()

Add Test Script to Package.json

Add the E2E test script to your package.json:

{
  "scripts": {
    "test:e2e": "tsx tests/app.spec.ts"
  }
}

You can now run your E2E tests with:

npm run test:e2e

Push to Repository

Now let's push our test-enabled application to a public repository:

# Remove existing origin
git remote remove origin

# Add your new repository
git remote add origin git@github.com:your-repository

# Push to the new repository
git add .
git commit -m "Add automated E2E testing with Browserless integration"
git push -u origin main

Once pushed, you can connect this repository to your Stormkit instance for automated deployments and testing.

Step 5: Configure Environment Variables in Stormkit

Now we need to configure Stormkit to use the Browserless endpoint for our tests.

Import from URL: In your Stormkit dashboard, click "Import from URL" and paste your repository URL

Set Environment Variables: Navigate to Environment > Config > Environment Variables and add:

Key: PLAYWRIGHT_WS_ENDPOINT
Value: ws://browserless:3000/chromium/playwright

Set a status check: Scroll down to Status Checks and provide the script we prepared above:

npm run test:e2e

Deploy: Click the "Deploy" button to start your first deployment

What Happens Behind the Scenes

When you trigger a deployment, Stormkit orchestrates several automated steps:

Build and Deploy: Stormkit builds your application from the repository and deploys it
Deployment Preview: A unique deployment endpoint is created and passed to your application via the SK_DEPLOYMENT_URL environment variable (which our test uses to know where to connect)
Status Checks: After deployment completes, Stormkit automatically runs the configured status checks (npm run test:e2e)
Validation: The status checks verify that your application loads correctly, required elements are present, and functionality works as expected
Production Promotion: If all tests pass, Stormkit automatically promotes this deployment to production, making it live for your users

This automated pipeline ensures that only validated, working deployments reach production, giving you confidence in your releases.

Conclusion

You now have a fully functional automated testing setup with Stormkit and Browserless! This configuration provides:

Scalable browser testing with Browserless
Automated test execution on deployments
Comprehensive test coverage for both UI and API

The combination of Stormkit's deployment platform with Browserless's browser automation creates a powerful testing environment that can scale with your application needs.

Hosting 300+ Websites - A Technical Deep Dive

Savas Vedova — Wed, 21 May 2025 16:18:29 +0000

It’s entirely feasible to host over 300 websites on a lean setup of just a few machines, and Stormkit makes it happen with a smart, scalable configuration. This post walks through the technical details how the infrastructure is set up, what it costs, how reliable it is, and what it takes to manage. Let’s dive in.

Infrastructure Setup

The foundation is a compact yet powerful hardware and software stack designed to handle hundreds of sites efficiently. These websites generate millions of requests per month, so reliability is a core concern.

Hardware

Machines: The production setup runs on 3 servers.
Specs: 2 vCPUs, 4 GiB RAM, SSD storage.
Cloud Provider: Alibaba Cloud, chosen for its compliance with local regulations.

Additional Resources

To support the hosting environment, we’ve added a few key components:

Network Load Balancer (NLB): A Layer 4 load balancer ensures TLS termination happens at the source, enabling automatic TLS certificate issuance.
Redis Instance: A Tair Redis OSS-compatible instance handles caching, keeps TLS certificates and acts as a message queue for storing logs and analytics.
PostgreSQL Database: Apsara DB RDS provides a reliable and managed database solution.
Staging Machine: A single server mirrors the production environment for testing and experimentation, keeping costs minimal.

Deployments

Frequent deployments are a hallmark of modern development workflows. Here’s how we’ve streamlined the process:

GitHub Actions Integration: Instead of scaling up worker servers, we offload CI/CD pipelines to GitHub Actions, which integrates seamlessly with Stormkit.
File Storage: All static files are stored and served from Alibaba OSS (S3-compatible object storage), ensuring fast and reliable delivery.

Software Configuration

Managing 300+ websites might sound daunting, but with the right tools, it’s surprisingly straightforward:

Monorepo Architecture: All websites are managed in a single monorepo, simplifying code management and updates.
Stormkit Snippets: Each website is customized using Stormkit’s Snippets feature. Conditional rules based on domain and path allow for unique configurations, ensuring every site has its own look and functionality.
Single Application, One Environment: All domains are assigned to a single Stormkit environment, reducing complexity and overhead.

Networking

Since the client primarily serves regional customers, global distribution wasn’t a priority. All resources are hosted in a single region, optimizing for simplicity and cost.

Cost Breakdown

Here’s how the numbers stack up:

Alibaba Cloud Resources: 4 servers, 1 database, 1 Redis instance, 1 NLB and around 300GB file storage cost approximately $1000/month with subscriptions.
Deployments: GitHub Actions is included in the client’s paid tier, so there’s no additional cost for CI/CD.
Stormkit Services: $500/month for infrastructure setup, service updates, monitoring, feature development, enterprise features and direct Slack support.

Total Monthly Cost: Around $1500.

Cost Per Website: Roughly $5 per site—a fraction of traditional hosting costs.

Reliability and Downtime

When hosting hundreds of websites, uptime is non-negotiable. Here’s how this setup performs:

Downtime: Virtually zero downtime over the last six months.
Resource Usage: Hosting machines maintain a CPU load of 0.8–1.9 and average memory consumption of 24%.
Efficiency: With Stormkit’s monorepo and API automation, updates roll out to all sites quickly, minimizing manual effort.

Key Takeaways

This setup demonstrates that hosting 300+ websites doesn’t require a sprawling infrastructure or a massive budget. With the right tools, a lean team can manage a large-scale operation efficiently.

Whether you’re managing a handful of sites or hundreds, this approach proves that scalability and cost-efficiency can go hand in hand.

Need Help with Your Infrastructure?

If you’re looking to optimize your infrastructure or streamline your deployment process, Stormkit can help. Our platform supports deployments for JavaScript (frontend and backend), Go, and Rust applications, offering unparalleled flexibility and control.

Contact us today to learn how Stormkit can transform your hosting and deployment workflows. Get in touch with us for more details.

Migrating your app from Webpack to Vite

Savas Vedova — Mon, 29 Aug 2022 09:49:00 +0000

Hey all 👋

I recently migrated Stormkit from Webpack to Vite and I wanted to share the changes because I had to follow a trial and error methodology to migrate it due to lack of documentation.

For those who'd like to see directly the code, here are the changes.

First thing you should know is that Vite uses esbuild for development and rollup for production. So while your development environment is working, your production build may fail. That was indeed the case for me and I'll explain in a moment why it happened.

Let's take a look to the configuration options used in vite:

import { defineConfig } from "vite";

export default defineConfig(() => {
  return {
    // Although this is called root, 
    // in our case this is "src", 
    // where our application logic is located. 
    // All configuration options defined 
    // afterwards will be relative to this endpoint.
    root: "src",

    // This is where our assets are served from. 
    // In webpack, this was "output.publicPath".
    base: "/",

    // This is similar to Webpack's DefinePlugin. 
    // It is used to inject constants in your application.
    define: { 
        // Using the following configuration made our build fail as 
        // mentioned above. I had to change a couple of `global` usages 
        // and remove this configuration to make them work.
        // global: { }
    }

    server: {
      // We need https for various 3rd party tools used 
      // in local environment. It is similar to 
      // Webpack Dev Server's 'server: "https"' config.
      // We require a certificate for this to work and that is 
      // achieved through the 'basicSsl' plugin.
      // You can check the actual code to see which package is that.
      https: true,

      // We are proxying all requests from `/api` to our api server. 
      // This config is very similar to Webpack Dev Server's proxy config. 
      proxy: { }
    }
  },

  // This is almost equivalent to Webpack's "resolve" config. 
  // It is used to import files using aliases.
  resolve: { },

  // Assets under this folder will be copied to the dist folder. 
  // We used to achieve the same functionality using 
  // the "copy-webpack-plugin" package.
  // Do not forget that this is relative to the "root" path configured above.
  publicDir: "./public",

  // List of plugins used to make various technologies work.
  plugins: [
     // used to add https to local environment
     basicSsl(),
     // used to include our bundles inside the html file
     createHtmlPlugin({}),
     // used to import svgs
     svgr(),
     // used to make react work with vite
     react(),
  ],

  build: {
    // Specify the dist folder
    outDir: "../dist"
  },

  // Loading a file was failing and adding this configuration
  // fixed it. It basically replaces top-level "this" usage
  // with the "window" object.
  esbuild: {
    define: { 
      this: "window"
    }
  }
})

We do use Tailwind and Material UI in our project. A simple postcss.config.js was all that I needed to make Tailwind work properly:

module.exports = {
  plugins: [require("tailwindcss"), require("autoprefixer")],
};

The rationale behind the migration

This definitely adds no direct value for the end user. So why did we migrate?

The main reason is because we'll make a lot of changes to the frontend soon as we're releasing a V2 for Stormkit. When I realised that the HMR was broken and I heard that Vite is extremely fast for development I decided to give it a try. Turns out, this was a pretty good decision and it will also add value to the end user because it'll increase our development speed.

Results

The build time seems to be a bit slower than our previous configuration. This is mainly because we used to use esbuild, which is extremely fast, for production builds but vite uses rollup. However, to be honest, given the increase in the HMR, we're willing to sacrifice a few seconds during production builds.
Whereas the HMR is extremely fast. When I make a change in the UI and switch to the browser to visualize it, I used to wait a few seconds till those changes were propagated. Now, by the time I switch the Browser tab, the changes are already there. This is fantastic!

Hope this mini tutorial was helpful to understand what is needed to migrate from Webpack to Vite. Stormkit is can be considered as a large application and the migration was possible through 1 PR with almost no breaking changes.

Note This article is also published on our blog.