How Stackbit Works

Walk through the core concepts of how Stackbit works by following a developer's typical journey.

Understanding how Stackbit works is easiest when we follow a developer's typical journey, where each step builds on concepts and practices from those before it.

You can put many of the concepts in this guide into action by following the getting started tutorial.

Working Modes

There are two working modes in Stackbit — local development and cloud projects.

Starting with Local Development

Developers typically start by working locally to build out a visual editing experience to suit their project's needs, while collaborating with content editors occurs in a cloud project, which is covered near the end of this guide.

Learn more about Local Development

Stackbit Development Server

Working locally with Stackbit is made possible by using the Stackbit CLI. The stackbit dev command runs in parallel with your site's development server to create a visual editing environment that enables developers to prepare a site before bringing in content editors.

See the CLI reference

Project Requirements

Stackbit is fully composable, which means that most content sources and site frameworks can be supported (with varying levels of required configuration).

Although Stackbit services a large variety of sites, the one thing all sites have in common — what we consider to be the sole prerequisite of a Stackbit site — is that content must be structured and separated from code. We think of this as having a content-driven architecture.

Read more on Content-Driven Development

Structured Content

For Stackbit to be able to empower editors to change content, that content must be structured, which means it has a predictable shape, as defined by a content schema.

Stackbit will inherit content schema when it is defined in the source. When Stackbit can't infer the schema (e.g. file-based content), you must provide a schema definition through the Stackbit configuration.

Structured content requirements

Stackbit Configuration

Stackbit's behavior for any given project is controlled by the Stackbit configuration file, stackbit.config.js|ts. Configuration is how Stackbit knows how to retrieve and store content, which content models represent pages, how editing features should work, and so on.

See the config reference

Connecting Content Sources

Perhaps the most critical configuration property is identifying the source(s) of a site's content, which is (usually) done through the contentSources config property.

Each content source implements Stackbit's Content Source Interface, the mechanism that enables two-way content sync between Stackbit and the source.

Learn about Content Source Interface

Content Editing

Once a site is properly configured, its content can be immediately edited through Stackbit.

Two-Way Content Sync

One of the most powerful capabilities of Stackbit is its two-way content synching mechanism, which provides the ability to:

  • Make changes from Stackbit that get saved back to the content source.
  • Update content in Stackbit when changes are made directly at the source.
  • Automatically update the site preview when content changes have been made.

Dive deep into Two-Way Content Sync

Traditional CMS Editing

When a content source is properly configured, all the models within source will be available to edit within Stackbit's content editor panel.

When working with content from a headless CMS, this requires no additional configuration, as Stackbit can automatically detect content models and fields from the CMS.

Learn more about the content editor panel

Content Tab
Content Tab

Basic Page Editing

To be able to edit with the page editor panel, you must tell Stackbit which models represent pages. This is typically done through the models property.

See `models` property reference

Page Editor Panel
Page Editor Panel

Advanced Editing

Editing can then be taken to the next level by enabling editing to click on elements in the preview and make the changes inline. This is made possible by annotating components by adding specific data attributes to inform Stackbit how the structure of your content maps the elements in the DOM.

More on inline editing

Edit Content Inline
Edit Content Inline

Reusable Content

As powerful as inline editing is, it's made even more powerful when content editors can reuse content. Although there are multiple ways to do this, Stackbit's content presets feature tends to boost editors' productivity the most.

Learn more about Content Presets

Component Presets View
Component Presets View


When it comes time to bring content editors into your project, you can create a new cloud project and begin inviting others. This is typically done by importing a GitHub repository into Stackbit, which kicks off a few other processes.

More on creating a project from a GitHub repo

Provisioning Services

When first creating a cloud project, Stackbit provisions services based on your site and configuration. While many of your services will already be configured, Stackbit does the following:

  • Production Site: Stackbit deploys your site to a [site] site on Netlify, unless your organization is configured to skip this step.
  • Container: Stackbit creates a container that powers the editing experience for your site. This replaces stackbit dev, used when working locally.

Provisioning configuration options


Once editors have been added to the Stackbit project, they can begin publishing content to production. This process can also be customized, though it is through the project settings.

More on Publishing and Git Workflows

Next Steps

This concludes the overview on how Stackbit works. Here are a few suggestions on what to do next.

Getting Started Tutorial

Follow the getting starter tutorial if you haven't. This provides a quick way to put some of these concepts into action.

Follow Getting Started Tutorial

Explore Documentation

We've covered a lot of the basics, but there are other features and concepts to explore.

Explore feature guides