Stormkit

Stormkit is a full-featured, self-hostable deployment and hosting platform built for teams that want the automation of Vercel or Netlify without surrendering control of their infrastructure. Written in Go, it runs as a collection of microservices — an API server, a hosting proxy, a build runner, and a background worker — all coordinated through PostgreSQL and Redis. You deploy from Docker images or pre-built binaries in under an hour.

Every push to a connected Git repository triggers an automated build-and-deploy pipeline. Stormkit handles static asset bundling via a custom esbuild-based bundler, serverless function packaging, redirect and header rule parsing, and upload to a configurable storage backend — whether that is AWS S3, Alibaba OSS, or the local filesystem. The hosting proxy serves deployed assets with automatic TLS via CertMagic backed by Redis for certificate storage, supports preview environments per pull request, and can enforce authentication walls at the edge.

The codebase ships in two tiers: Community Edition (AGPL-3.0) covers the core build, deploy, and hosting pipeline; Enterprise Edition (commercial license) adds analytics, audit logging, and team management. Both tiers are present in a single repository, making it straightforward to understand where CE ends and EE begins. A React 19 and Material UI frontend, also included in the repo, provides the management dashboard.

Stormkit is a strong fit for platform engineering teams, agencies managing many client sites, or organizations that must keep application data and builds entirely on their own infrastructure while still wanting a polished deployment experience.

What You Get

• Automated Build Pipeline - On every Git push, Stormkit clones the repository, detects the package manager, runs the build command, bundles static assets and serverless functions using an embedded esbuild runtime, and publishes the result to your configured storage backend.
• Preview Environments per Pull Request - Each open pull request automatically gets a unique live URL with its own environment variables, letting QA reviewers and designers inspect changes before they reach production without any manual steps.
• Custom Domain Management with Auto-TLS - The hosting microservice uses CertMagic backed by Redis to provision and renew Let’s Encrypt TLS certificates automatically for any domain you point at your Stormkit instance.
• Serverless Function Execution - Applications can expose Node.js or Bun serverless functions alongside their static frontend; Stormkit packages them separately during the build and routes API calls through the hosting proxy.
• Multi-Environment Configuration - Each application environment (production, staging, preview) carries its own set of environment variables, redirect rules, custom headers, and snippet injections, all managed through the dashboard or API.
• Pluggable Storage and Cloud Backends - Supports AWS S3, Alibaba Cloud OSS, and a local filesystem provider out of the box, with Lambda and Alibaba Functions as serverless runtimes, letting you deploy to whichever cloud you already operate.
• Background Job Worker - A dedicated workerserver service handles async tasks such as domain validation, analytics aggregation, environment teardown, and log shipping, keeping the API and hosting paths responsive.
• Enterprise-tier Analytics and Auditing - The commercial EE tier adds bot-filtered web analytics, an audit trail for all administrative actions, and team-based access control with roles and permissions.

Common Use Cases

• Agency managing dozens of client sites - A web agency connects each client’s GitHub repository to Stormkit, configures per-client custom domains, and lets Stormkit handle build-on-push and TLS renewal automatically, eliminating per-site DevOps overhead.
• Regulated enterprise moving off public PaaS - A fintech company cannot send source code or build artifacts to third-party SaaS platforms; they run Stormkit on their private AWS VPC, pointing S3 and Lambda at internal accounts so every build stays within their compliance boundary.
• Open-source project hosting preview docs - A developer tool publishes auto-generated documentation on every PR so contributors can view rendered output before merging, using Stormkit’s preview environment URLs shared in PR comments.
• Full-stack React app with serverless backend - A startup ships a React SPA with a Node.js API layer; Stormkit’s runner detects the API folder, bundles it separately, and routes requests through the hosting proxy, removing the need for a separate API-hosting service.
• Internal tooling platform for an engineering team - A platform team standardizes all internal tools onto a single Stormkit instance with an authentication wall at the edge, so only company SSO users can reach deployed services without modifying application code.

Under The Hood

Architecture Stormkit is structured as a set of loosely coupled microservices — an HTTP API server, a static/serverless hosting reverse proxy, a build runner, and a background worker — that communicate through a shared PostgreSQL database and a Redis message bus. Each service is compiled to its own binary and shipped as a separate Docker image, enabling independent scaling. The API server uses a service-registration pattern with gorilla/mux under a thin custom router abstraction; feature handlers register themselves at startup, and the router applies middleware for CORS, timeouts, and authentication before dispatching requests. The hosting proxy intercepts incoming HTTP(S) requests by virtual host, looks up the matching application environment from the database or an in-process cache, fetches the deployed bundle, and streams assets directly to the client. The build runner operates as a stateless subprocess that clones a repository, auto-detects the package manager, runs the configured build command inside an isolated working directory, and invokes an embedded esbuild-based bundler to package static assets and serverless functions before uploading artifacts to the configured storage backend. The worker service processes background jobs — domain certificate renewal, deployment log aggregation, environment teardown — in named queues backed by Redis-distributed locking to prevent duplicate execution across horizontally scaled instances.

Tech Stack The backend is written in Go 1.25 and uses gorilla/mux for HTTP routing, GORM-style raw SQL statements against PostgreSQL 14+ via pgx, Redis 7 for caching and distributed coordination, and CertMagic with a Redis storage adapter for automated TLS certificate lifecycle management. The build runner embeds esbuild for zero-dependency JavaScript bundling and supports AWS S3/Lambda, Alibaba Cloud OSS/Functions, and a local filesystem provider as interchangeable storage and compute backends. Cloud provider integration uses the official AWS SDK v2 and Alibaba Cloud SDK. The React 19 and TypeScript management dashboard is built with Vite, Material UI 7, CodeMirror 6 for in-browser code editing, Recharts for analytics charts, and Tailwind CSS for utility styling. Automated backend tests run with Go’s standard testing package complemented by mockery-generated testify mocks; frontend tests use Vitest and React Testing Library.

Code Quality The backend demonstrates comprehensive testing discipline with extensive unit and integration tests across all major subsystems — over two hundred test files covering the API handlers, hosting proxy, build runner, bundler, deployment model, and worker jobs. Mocks for all shared interfaces are generated systematically using mockery and committed to the repository, making test setup explicit and deterministic. Error handling follows Go idioms: errors are propagated as typed values, logged at call boundaries with structured zap logger fields, and surfaced to callers rather than swallowed. The codebase uses consistent naming conventions aligned with Go community standards, and shared utilities are isolated in a lib package consumed by both CE and EE components. A Makefile-driven build enforces test runs and formatting checks. The frontend has limited test coverage by comparison, with only a small number of Vitest tests present, though it benefits from TypeScript strict mode throughout.

What Makes It Unique Stormkit’s most distinctive property is that it ships the complete deployment platform — build runner, hosting reverse proxy, TLS automation, serverless routing, and background workers — as a single repository that self-hosters can fully operate without any dependency on the vendor’s cloud. Most open-source deployment tools provide only the CI/CD layer and delegate hosting to object storage or a separate CDN; Stormkit unifies the hosting proxy with CertMagic-based automatic TLS so a single Docker deployment handles both the build pipeline and the live serving of applications. The multi-cloud abstraction layer — swappable S3/OSS storage and Lambda/Alibaba Functions runtimes selected at configuration time — lets operators target whichever cloud account they already run without code changes. The clear AGPL/commercial dual-license split within a single repository, with src/ce/ and src/ee/ directories mirroring each other in structure, also makes it unusually transparent about which capabilities require a paid license.

Self-Hosting

Stormkit’s repository is governed by a dual-license structure. The Community Edition, located in src/ce/ along with the shared src/lib/ utilities, is published under AGPL-3.0. This means you are free to use, modify, and self-host the CE without paying Stormkit OÜ, but AGPL’s network copyleft clause applies: if you modify the CE and offer it as a service to external users, you must make your modified source code available to those users. Commercial use is permitted under AGPL-3.0, but the copyleft obligations follow the software wherever it runs. The Enterprise Edition, in src/ee/, is proprietary and requires a commercial license purchased from Stormkit OÜ; no rights to use, distribute, or modify EE components are granted without that license.

Running Stormkit yourself is a genuine multi-service operation. The minimal stack requires PostgreSQL 14+, Redis 7, and at least two Docker images (the API/workerserver and the hosting proxy). For a production-grade deployment you will also need an S3-compatible object store for build artifacts, a DNS setup that points application domains to your hosting proxy, and infrastructure to run the build runner, which executes user-supplied build commands in a subprocess — a significant security surface that requires careful sandboxing in multi-tenant scenarios. Certificate renewal is automated via CertMagic, but you are responsible for the PostgreSQL and Redis availability, backup, and failover. Database schema migrations are versioned in src/migrations/ and must be applied manually on upgrades. Expect meaningful platform engineering investment to reach a stable, monitored production configuration.

The managed Cloud Edition at app.stormkit.io removes all of that operational burden: Stormkit OÜ handles uptime, scaling, certificate management, database backups, and upgrades. The CE self-hosted path gives you the core build and hosting pipeline; the EE tier — available to both cloud and self-hosted customers with a commercial license — adds web analytics with bot filtering, a full audit log of administrative actions, and team-based role management. If you need SLAs, dedicated support, or high-availability guarantees, those come through a commercial agreement with Stormkit OÜ rather than from the community license.