Stackbit lets you and your team preview and edit your Jamstack site without the need to rebuild and deploy your site's preview every time its content is changed. The preview always reflects the latest and unpublished state of your site.

How it Works

Content Ownership and Bidirectional Content Sync

Stackbit runs your site's development server and proxies page requests from your browser to that server. Any content or code changes you make within Stackbit are immediately synchronized with your headless-CMS or committed and pushed to the special preview branch in your git repository if your site stores its content in Git. This synchronization also works the other around - Stackbit preview immediately reflects any changes you make to your content within the headless-CMS or Git. Stackbit never stores your content and always gets it from where you keep it. We believe in the idea that everyone should own their content.

WYSIWYG Editing with No Code Changes

While editing your site content, you can enjoy the automatic on-page editing functionality. In most cases, you don't need to do anything special for this functionality to work. And in case your site doesn't use any headless-CMS, you will only need to define your site's content model in stackbit.yaml, and the rest are on us.

Your Own Deployment

Stackbit doesn't intervene with your existing CI/CD tools. Once you decide to publish changes, Stackbit will publish objects in your headless-CMS and/or merge the preview branch into the main branch. Your deployment tool will handle the rest according to how you defined it. For example, your serverless deployment platform might trigger new deployment when a new commit is pushed to the main branch or when the headless-CMS calls one of its "content-publish" webhooks.

Prerequisites

Of course, we could not allow all these great things without setting some limitations and prerequisites described below.

  • Stackbit supports sites built using one of the following SSGs - Gatsby, Next.js, Eleventy, Gridsome, Hexo, Hugo, Jekyll, Next.js, Nuxt, Sapper, Vuepress.
  • Your site's content is separated from the presentation. For example, if your site uses React, then the content should be stored separately and passed to React components via props. If you want to learn more about separating content from presentation, read our conceptual guide on this subject.
  • Your site's content is stored in files in your site's git repository. These files should have one of the following extensions - .md, .mdx, .markdown, .yaml, .yml, .json, .toml. Alternatively, your site's content is managed by one of the supported CMS's - Contentful, Sanity, Forestry, NetlifyCMS.
  • Your site has a content schema, either defined in a headless-CMS or defined inside stackbit.yaml.
  • Your site has a working development server that listens to content changes in files or headless-CMS and refreshes any opened browser sessions via live-reload or HMR when the content is changed.