Content from Storyblok should not be seen as a 1:1 match to your development set-up. You might have multiple different stages for your development cycle that would not affect content since its only layout, structure or styling changes. Below you can find two concepts that show how a multi staged development set-up can be matched with Storyblok spaces.

Concept 1

In this inital concept we do have 4 development / technology environments. You can now decide which of those environments you want to connect to one of your spaces. We - in general - recommend using at least two spaces once you're done with development.

The Local and QA technology environment are configured with the access token of a Storyblok Development space. You can create that space from production by duplicating it in the interface. This allows you to try out new component definition, change the schema of existing components and rearrange content as you might need to do later on production without affecting that.

To migrate new components and content changes over to the Storyblok Production Space you can use our CLI which allows you to pull and push components from one space to another, and also to version your components as a JSON file in your code.

Once you get the OK from QA you can activate a maintenance option in the Production Space and access the Migration. We would recommend to execute an S3 backup beforehand so you are able to easily revert to a previous version.

Concept 2

In this concept we still have four development environments, however this time we increased the number of spaces in Storyblok to three. With that we can also test the migration of the components and content changes from Development to Staging. Once QA that gives a green ligth we can than execute the same migration on the production space using the Storyblok CLI. The advantage by adding another space for QA you can already start building new components in the Development space and your QA will not be confused by other options and might report "non bugs".