Stackbit websites are Jamstack projects based on open-source tooling. That means there are a variety of attractive options for you when you outgrow the default hosting that comes with all of our plans.

The Default Hosting

When you create a new project, Stackbit automatically deploys a live website based on the initial contents of the projects. Both this live website and the preview you work with in Stackbit look exactly the same. However, the live website is optimized for production, and its URL is public.

This public URL is auto-generated based on your project name, plus a random string to make this URL not easily guessable. This URL will not appear in any search index or be shared anywhere on its own. It is your choice when to start sharing this URL or link to it, or whether to do so at all.

If you want to take your site public, you would probably want to first connect your own domain to it instead of sharing the auto-generated name.

Currently, our default hosting is based on Netlify. However, this may change in the future without affecting the functionality of your Stackbit-managed websites, or having you perform any maintenance. We do not offer features that are proprietary to the hosting vendor we work with.

Should I Use the Default Hosting?

Stackbit offers hosting by default for two reasons:

  • Simplicity: You begin your project with a live website without additional configuration.
  • Convenience: The Publish button in the visual editor will update its state to notify you when the publishing of new changes is complete, and if there are any issues you have access to the deployment logs within the UI.

However, the default hosting is not always the best fit. Here are a few reasons why:

  • Capabilities: You don't have access to the hosting vendor's dashboard or value-added features. For example, you cannot set up environment variables that have a different value for the live website than those used in the visual editor environment.
  • Governance: There may be a policy in your organization mandating that all websites are deployed by a technical team based on their own stack.
  • Scale: The default hosting is not meant for high-volume websites or for making large files available for download.

In these or other similar cases, consider transitioning to your own hosting solution.

The last section in this guide contains additional considerations to make when using your own solution.

Other Hosting Solutions

There are numerous options for deploying Jamstack sites, should you choose to implement your own solution.

Deploying with Jamstack-Oriented Hosting Providers

Both Netlify and Vercel (creators of Next.js) are good options. Both currently support all Next.js features out of the box (though you can expect Vercel to always be first to support experimental features). Both offer proprietary added features to stand out from the crowd.

Deployment Guides
See the following guides for help in deploying to Jamstack providers:

Deploying with the Major Cloud Providers

Generally speaking, the main benefit to using any of the general-purpose cloud providers for hosting your Jamstack website is interoperability with any other cloud services your organization may be using. You will be able to utilize the advanced permissions model these providers offer, plus minimal network latency between services.

AWS: AWS offers the most out-of-the-box solution via their Amplify service.

Google Cloud: You can use Cloud Run to deploy a Dockerized version of Next.js. There are more steps for you to perform than in the options above, but you won't have to manually provision, maintain and scale servers.

Azure: The Azure App Service offers a comparable experience.

DigitalOcean: You can use a Custom Server to deploy your site.

Not all of these services automatically serve your site through a CDN, which is highly recommended. Nor are they all configured to run server-side features, should you choose to enable them.

Roll Your Own, Anywhere

Stackbit sites are statically exported by default. That means you can grab the files in the out directory after a build and host them anywhere.

Should you choose to enable server-side capabilities, you can run Next.js anywhere you can run either Node.js or Docker, which means pretty much everywhere.

In both of these cases, getting the deployment right, triggering new deployments on changes to the Git repository, serving through a CDN and scaling servers as needed are all considerations that are left to you.


If you're on our paid plans and having difficulty choosing what deployment method to choose, talk to us!

Additional Considerations

There are a few important considerations when choosing your own deployment method and hosting solution.

Stackbit's Default Deployment

Transitioning to your own hosting solution will not remove or delete the default live site provided by Stackbit.

Handling Form Submission

Stackbit's form submission is the only back-end functionality that sites come with by default. If you use your own hosting solution and are also using Stackbit's form submission process, there is additional work required to ensure form submissions continue to work. See this guide for more information.