Why you don’t need a traditional development environment with Blocks

For years, many organisations have defaulted to the idea that every project must have a development environment, which is an entire clone of everything in production including your CMS. It’s seen as a “best practice” and sits alongside production. But in practice, this model adds unnecessary complexity for most teams, and when working with Blocks inside of the Contensis deployment platform, it’s rarely needed at all.

Blocks are part of the Contensis deployment platform. They provide a managed environment where your headless website or app can be deployed, updated, and scaled – all without your team needing to run its own hosting infrastructure.

We built the Contensis deployment platform because while headless CMSs give organisations flexibility and control, they also introduce a new challenge – where do you actually host and run your front end? Many organisations told us they didn’t want the cost, complexity, or operational overhead of managing a separate deployment platform alongside their CMS. Blocks solve this by giving you a fully integrated deployment platform inside Contensis.

Each Block is a container for your code that runs alongside your CMS content in production. You can:

• Deploy multiple branches of your code, so you can test new features without affecting your main site.
• Use staging URLs to validate changes before go-live.
• Preview feature branches independently, making it easy to gather feedback before release.

This model means your code and content always live side by side, with built-in safety nets for testing and review. For most teams, that eliminates the need for a separate development environment.

Blocks introduce a different way of thinking about environments. Because you can run multiple branches of code in your production environment, you no longer need a dedicated development environment just to preview or validate changes.

Want to test a feature branch? Deploy it as its own Block and preview it directly.

Want to validate changes before go-live? Use the staging URL, which always shows the latest version of main that’s ready but not yet released.

This means every environment you need – preview, staging, and production – is effectively built into the Blocks workflow without the cost of maintaining a separate development stack.

There are limited, specific cases where a development environment could play a role. These are typically situations where large-scale changes need to be validated in isolation before they affect your main system:

For example, validating a new version of Contensis itself before rolling it out across your organisation.

If you are restructuring content types or schemas that affect many templates, testing those changes in a separate environment first can reduce risk.

If you are importing or transforming a large volume of content in one go, it may be safer to trial this in a development environment before touching production.

Outside of these scenarios, most day-to-day development and testing flows are better served by Blocks’ branching and staging capabilities.

It’s worth stressing that having a “development CMS” – separate from staging and production – is actually unusual in modern digital teams for three reasons:

Synchronising content, managing upgrades, and maintaining parity between environments takes unnecessary time and risks introducing errors.

Content editors don’t know which environment to use, and developers struggle with drift between development, staging and production.

Most importantly, a development CMS is redundant when your deployment model already supports isolated, testable branches of code in production.

With Blocks, your CMS content and your code run side by side in production, with safety nets like staging URLs and feature branch previews. This reduces duplication, simplifies workflows, and eliminates the need for a separate development CMS.

Blocks are designed to remove unnecessary complexity.

The old dev → stage → prod setup made sense when deployments were heavy, manual, and risky. Today, you don’t need to carry that overhead. With Blocks, your content and code run side by side in production – with safety nets built in.

The result is a simpler, more reliable workflow where dedicated development environments are the exception, not the rule. That means your teams can spend less time managing environments and more time building great digital experiences.

If you’d like to dig deeper, you can explore our Blocks documentation to see how they fit into different workflows.

And if you’re already working with Contensis, it’s worth asking your team how Blocks could streamline the way you build and release projects.

For those looking at Contensis for the first time, we’d be happy to show you Blocks in action.