FAQ

Both are deployment platforms that take your code and run it. Stormkit hosts static sites, single-page apps, server-side rendered apps, serverless functions and long-running server processes, in any language — runtimes are provisioned with mise, and system-level packages can come from a flake.nix. On top of deployment it ships a PostgreSQL database, end-user authentication, a mailer, periodic triggers and analytics, so you are not assembling those from separate vendors.

The bigger difference is that Stormkit can be self-hosted on your own infrastructure, which is what most people are looking for when they compare the two.

Yes. On a self-hosted instance, set a Start command and Stormkit runs your server as a long-lived process — see Application runtime. This is the recommended way to run backend code when self-hosting, and it is not limited to Node: a Go, Python or Ruby server works the same way.

On Stormkit Cloud, backend code runs as serverless functions — same interface as Node.js request handlers — which are stateless, short-lived and subject to a 15 second timeout. If you need long-lived processes, connection pools or a warm cache, self-host.

Certainly! Stormkit can provision a PostgreSQL database for your environment and run migrations on deployment. You can also connect to an external database by injecting its credentials as environment variables into your backend functions.

If your repository encompasses multiple projects, Stormkit offers two approaches for deployment. Firstly, you can create distinct projects within the same repository and set up automated deployment based on branch naming conventions. For instance, if your repository hosts both frontend and backend applications, establish two projects triggering deployment when branches start with fe- and be- respectively. Configure these settings in the environment's configuration section.

Alternatively, you can create two separate environments within a single app, one for frontend and the other for backend. Utilizing the SK_CWD variable, you can build each project accordingly. As before, deploy triggers can be set up based on branch naming conventions.

Yes, we leverage specific AWS solutions such as Lambda and S3 to enhance our services. Our approach involves utilizing certain AWS services to minimize dependence on AWS. This strategy ensures our platform's adaptability for potential portability to on-premise environments or alternate cloud providers in the future.

As of May 21, 2023, we have made the decision to drop serverless support for Next.js. You can still use Next.js but you won't able to SSR.

At Stormkit, we're dedicated to offering an exceptional user experience through our carefully crafted product. As Stormkit is self-funded, we're investing our energy into developing a solution that truly addresses your requirements.

To maintain our commitment to quality, our cloud solution remains as a paid service, whereas self-hosted users can explore freely the product. This approach enables us to focus on users genuinely interested in exploring our offering.

It's crucial to understand that we're entirely self-funded, without external backing. Our product's growth and development rely solely on revenue generated.

Should you desire an extended trial or a different package, don't hesitate to reach out. As a self-funded entity, we prioritize flexibility in accommodating our customers' financial situations.

Yes.

Yes.

Stormkit employs robust security measures to safeguard your data. This includes encrypting data on disk using the highly secure 256-bit Advanced Encryption Standard (AES-256). Your valuable customer data is backed up hourly to ensure its safety. Additionally, we prioritize security by default through our utilization of HTTPS/SSL protocols.

We're prepared for unexpected traffic spikes. Our platform is designed to scale dynamically, automatically adjusting resources to meet demand. This ensures that your applications remain responsive and available, even during periods of sudden increased traffic.