Documentation

Working with environments

Elevate, May 20-22-2025, Miami Beach, Florida

Environments in the Studio let you manage different versions of your website for development, staging, and production.

General concepts

Access to environments

In the Studio, you can work in the following environments:

  • Production: it is connected to your production API hub (for example, exampleshop-examplecompany.frontastic.live), which is the information source for your production site on Netlify (for example, https://exampleshop-examplecompany.production.frontend.site).
  • Staging: it is connected to your staging API hub (for example, exampleshop-examplecompany.frontastic.io), which is the information source for your staging site on Netlify (for example, https://exampleshop-examplecompany.frontend.site).
  • Development: it is the information source during local development on localhost:3000. You can send requests to the extension runner by using a hostname with the this structure PROJECT_NAME-COMPANY_NAME.frontastic.rocks (for example, exampleshop-examplecompany.frontastic.rocks).
Access to environments in the Studio depends on your user role, only Admin and Developer users can edit in all environments.
As a general rule for using the Studio, we recommend assigning users the roles that best suit them. We suggest granting business (non-developer) users access to the production environment only and developer users access to all environments. However, this is not a constraint and you are free to assign roles according to your needs.

To switch between environments, use the drop-down in the top-right corner.

The Studio homepage with environment drop-down open with the following options: Production, Staging, and Development.

Environment hierarchy

The hierarchy of environments is the following, where 1 is the highest level.

  1. Production
  2. Staging
  3. Development

Information available in an environment is also available in lower-level environments, but not in higher-level environments, therefore:

  • Information in development is available in development only.
  • Information in staging is available in staging and development.
  • Information in production is available in production, staging, and development.

Information can be edited in the highest-level environment it is present in and the changes will also be applied in the lower-level environments. For example, if a page folder is present in both the development and staging environments, you can only edit it in staging and changes will be applied in development too.

Exceptions apply to the Media, Redirects, and Team areas and to project setting configuration.

Promote and demote information

Admin and Developer Studio users can set for which environments a piece of information is available. As long as you edit a piece of information in the highest-level environment it is present in, you can promote it to a higher-level environment or demote it to a lower-level one.
To do so, use the environment selector in the corresponding settings section. For example, if a page folder is available in the staging environment and you want to promote it to the production one, go to the page folder's settings section, select Production from the selector, and save.
The environment selector with the three environment icons

Media, Redirects, and Team

Information in the Media, Redirects, and Team areas is the same in all environments, regardless of the hierarchy. For example, if you add an image to the Media area in the development environment, it will be available in the staging and production environments too.

Schemas

You can add schemas for Frontend components and data sources in any environment. However, you can add schemas for dynamic pages, page folders, and project settings only in the production environment.

Project settings configuration

Although the project settings schema follows the environment hierarchy, the project settings configuration is environment-specific. This means that for the same fields in the project settings schema, you can set different configuration values in each environment.
If you edit the project settings schema, for example, by adding some fields, the new fields will appear in the Project settings area in all environments, but the existing configuration values will remain different for different environments.

Work with environments as a business user

Following are suggestions on handling some common scenarios for a business user.

Edit a live page version

To edit a page version that is live in production, we recommend following these steps:

  1. In the production environment, duplicate the page version by clicking the More icon and selecting Duplicate.
  2. Edit the duplicate in the page builder.
  3. If needed, request a review of the changes.
  4. Publish the duplicate page version containing the changes by clicking Make live or schedule the publication.
This applies to all page versions, the one associated with page folders in the Site builder area, with dynamic pages in the Dynamic pages area, and with page templates in the Templates area.

Edit a live component group

To edit a component group that is live in production, we recommend following these steps:
  1. In the production environment, duplicate the component group.
  2. Add the duplicate component group to a page version and test the changes.
  3. When tests are successful, apply the same changes to the original component group and save them.
  4. Delete the duplicate component group.

Create and edit page folders

To create and edit page folders, we recommend working in the staging environment first and test the changes there.

To create a page folder, we recommend creating it in the staging environment and testing it. When tests are successful, make the page folder available for the production environment by using the environment selector.

To edit a page folder that is live in production, we recommend following these steps:

  1. In the staging environment, duplicate the page folder by clicking Duplicate.
  2. Edit the settings of the duplicate page folder.
  3. Test the changes and, when successful, apply the same changes to the page folder in the production environment.
  4. Delete the duplicate page folder in the staging environment.

Work with environments as a developer

Create a component

The following procedure describes a sample basic flow for the development of a Frontend component to give you an idea of how you can leverage Studio environments.
  1. Create the JSON schema for the Frontend component.
  2. In the development environment, upload the JSON schema from the Components area.
  3. Develop the React code of the Frontend component locally.
  4. If needed, in the development environment, create a page folder and a page version in the Site builder area.
  5. In the development environment, edit a page version by adding your Frontend component to test it:
    • If the Frontend component looks good, go to step 6.
    • If the Frontend component does not look good, go back to step 1.
  6. Deploy your Frontend component to staging by merging the code into your master branch. If the build is successful it should be deployed automatically.
  7. In the development environment, from the Components area, promote the Frontend component schema to the staging environment using the environment selector.
  8. Request a business user in your team to test the Frontend component on a page version in the staging environment. It is also possible to check the component on the deploy preview of your staging site.
    • If the Frontend component looks good, go to step 9.
    • If the Frontend component does not look good, go back to step 1.
  9. Deploy the build with the Frontend component to production from the Deployment area.

    In this example, we assume that the production API hub has already been set up. Usually, we set it up when you start planning the go-live for your website.

  10. In the staging environment, from the Components area, promote the Frontend component schema to the production environment using the environment selector.
  11. Request a business user in your team to test the Frontend component on a draft page version in the production environment. It is also possible to check the component on the deploy preview of your production site.
    • If the Frontend component looks good, it is ready for use.
    • If the Frontend component does not look good, go back to step 1.

Edit a live component

To edit a Frontend component that is used on live page versions in production, we recommend following these steps:
  1. In the production environment, select the component in the Components area and copy its schema by doing one of the following:
    • Click Edit schema, click the Copy icon in the schema editor, then click the back arrow to close the schema editor.
    • Click Download component schema to download the schema file on your computer.
  2. Add the copy of the component schema to the Components area. In the schema editor, rename the component by editing the value in the tasticType field and the value of the name field in the schema.
  3. In the Components area, select the duplicate component and demote it to the staging or development environment with the environment selector.
  4. In your Frontend project repository, duplicate the component folder in the tastics folder and rename it.
  5. In the JSON file, edit the tasticType and name fields based on the values you entered in step 2.
    In the tsx file, apply the required changes to the Frontend component code.

  6. Deploy your changes and test the duplicate component on the page versions in the development or staging environment.

  7. When tests are successful, push the code of the duplicate component to production. Then, in the Components area, promote the duplicate component to the production environment with the environment selector.
  8. In the Components area, select the original component. In the Component usage section, check where the component is used and replace it with the new one.