- Learn
- Concepts
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.
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.
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.
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
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
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.
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
Collaboration
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].stackbit.appsite 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
Publishing
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.
Join the Community
Join the Discord community to get support and provide feedback about anything related to Stackbit (including this document). And feel free to contact us directly at any point for questions, issues, and ideas.