What are environments?

Flexible safeguards with environments

Environments not only provide a safeguard for your production environment but also grant you the flexibility to execute specific functions, such as seamless migration between different environments.

Environments and their use

Environments are a tool for testing purposes, not for content production.  For example, if you need to adjust the existing content model or programmatically modify hundreds of items, we recommend using a non-production environment to test the change before making it in production. By default, every Kontent.ai project comes with an environment called Production. You can rename this environment to anything you like, such as main or live. As long as the environment is marked as production, it cannot be deleted. For content production and preview purposes, use an environment marked as production.

The purposes environments serve

You can have different environments for several dedicated purposes while keeping the production environment untouched. Think of non-production environments as sandboxes for development and experimentation.

Experiment with changes in a safe space

Environments empower you to safely experiment with content types or restructure your content models without the risk of affecting the live production environment. This ensures that any modifications or additions can be thoroughly tested and reviewed before implementation. You can:

• Modify and test content model changes.
• Test content migration scripts on your content types and content items.
• Import data from other systems into your testing environment during development.
• Extend your content model and related content items while adjusting your app.
• Deploy modified content models to the potential production environment through migration.
• Create testing content in a non-production environment to check how your app handles edge cases.

Build new features in the development environment

A dedicated environment for development provides a workspace where you can:

• Work on developing scripts for integration and migration.
• Perform rigorous testing.
• Validate content types and your overall content model.

You can also set up a test preview to see the changes. For example, this can be a web app that visualizes your changes in a controlled setting.

Review in the staging environment

The staging environment can be dedicated to reviewing and testing content model changes or new features before going live. In this environment, editors or content managers can further test what changes were promoted from development before they reach production, without requiring access to the development environment. You can make sure that everything developed and coded from the development environment is working before applying these changes to the live production environment.

Go live using the production environment

The production environment is the live, public-facing version of your channels. This environment contains the draft and finalized content that your customers and end users will interact with upon publication. Any approved changes in your content types or new features can be migrated to an environment marked as production.

Example: Your environment operation strategy

Start by defining your environment strategy – the foundation of your content and development pipeline. This includes:

• Defining environment roles and responsibilities.
• Identifying the source of truth (usually production) and transitional environments.
• Deciding which environments to sync and if a backup is required.
• Mapping the flow of content and development changes.

Core setup: development and production

This setup is widely recommended because it strikes the right balance between simplicity and operational control. With only development and production environments, your teams can minimise the complexity and overhead of syncing, which becomes increasingly difficult as more environments are added.  Editors and content creators are kept in the production environment, where permissions and workflows prevent accidental publishing, while developers have a separate environment to experiment freely. This separation ensures stability, reduces risk, and supports a clean and efficient process for most use cases.

Expand your environment setup

While development and production environments are sufficient for many teams, you may benefit from expanding the setup to support specialised processes or risk mitigation strategies for greater flexibility and control. Common optional environments include:

• QA or Staging: Use this environment to test and validate model changes before promoting them to production. The QA or staging environment acts as an approval gate—if changes are rejected, your production environment remains untouched.
• Backup: Create a backup environment before making major model changes. This gives you a rollback point in case of unexpected issues.
  • For routine backups, Kontent.ai offers disaster recovery measures. 

Visualise your requirements 

Use visual diagrams to map the environment flow for better planning, smoother collaboration, and to make the overall process more reliable. A clear environment strategy flow map may look something like this.

What are environments not for?