The reality of GitOps application recreation

Your application code is in Git, and you’ve adopted GitOps principles, so you can recreate it anywhere, anytime, right? If you’re like many teams, the honest answer is “sort of”. While GitOps promises the ability to recreate your application from version control, the reality is often more nuanced as you consider the holistic view of deploying and running your applications.

Our State of GitOps report reveals some fascinating insights about recreatable applications. As part of the survey, we asked this question:

Can you recreate the application from the configuration files stored in version control, for example, to recover from a disaster or to create a new test environment?

Overall, 52% of respondents feel confident they can recreate their applications from version control. For high-performing GitOps teams, this jumps to 70%. But what caught my attention is that “partially recreatable” was a significant response across GitOps maturity levels and the most common response among teams still developing their GitOps practices. It suggests that while most teams can handle their core applications, they struggle with recreating the complete environment stack.

Interestingly, our data reveals that teams often become less confident about recreation as they advance their GitOps practices, only to see confidence surge at higher maturity levels. This pattern likely reflects a natural discovery process. As teams dive deeper into GitOps, they uncover dependencies and complexities they didn’t initially realize existed.

So, what does complete application recreation entail? And why do so many teams find themselves in that “partially recreatable” category?

The real-world value of recreatable applications

Recreatable applications don’t make sense for all organizations and applications and arguably could be viewed as nice to have rather than a necessity. However, recreating your applications from Git can solve real problems teams face at different scales and circumstances.

When disasters occur, having your entire application stack defined in code means restoration becomes a deployment rather than a scramble. You can rebuild from your Git repository instead of hunting through documentation or recreating manual configurations. The same capability proves valuable during cloud provider migrations driven by acquisitions, regulatory requirements, or strategic business decisions, where recreation becomes a non-trivial but controlled transition rather than a risky lift-and-shift operation.

Of course, your application is just one piece of the puzzle. You’ll still need to consider the surrounding infrastructure, networking, and foundational services that enable your application to run in the target environment. While mature teams often manage this infrastructure through tools like Terraform and Crossplane, getting to that level of complete recreation from Git requires thoughtful planning and infrastructure provisioning processes.

Operational efficiency improves when you can create new test environments on demand with minimal overhead. Whether you’re testing critical fixes, running performance tests against production-like infrastructure, or validating new features, the ability to spin up identical environments quickly and tear them down when finished reduces both time and infrastructure costs.

Recreation provides auditable proof for regulated industries that infrastructure and deployment processes are fully documented and reproducible. Suppose you need to satisfy compliance frameworks that require demonstrable change control. In that case, recreatable applications help you meet audit requirements for deployment consistency and provide evidence that you can rebuild systems according to documented specifications.

The maturity journey

Our survey data’s confidence curve tells a story about how teams learn and adopt GitOps. Rather than steady upward progress, there’s an initial dip in confidence before teams reach far higher levels of certainty about their recreation capabilities.

This pattern might highlight the natural learning process. Pre and low adopters will typically approach GitOps from an application-down perspective and focus on getting their manifests into Git repositories. The initial confidence may come from successfully deploying applications this way and feeling like they’ve “solved” recreation.

However, as teams mature, reality sets in when they add more applications to their GitOps processes and try to recreate complete environments. They likely discover their core applications are relatively easy to recreate, but the surrounding environment may not be. Infrastructure provisioning may be required, whether manual or automated, and teams may not have accounted for external dependencies yet.

You need backup and restore strategies for stateful components like databases that go beyond what you define in Kubernetes manifests. While the application might be recreatable from Git, the data likely isn’t. You’ll consider whether to increase cost and complexity by replicating databases across infrastructure, configure automated backup and restore processes, or accept that provisioning new environments require data restoration as a separate step.

This explains why “partially recreatable” was a popular response in our survey across all GitOps maturity levels. Most teams can handle their core applications but struggle with the complete environment stack. As low and medium-maturity teams adopt foundational GitOps practices, they discover the full scope of what requires management, decreasing their confidence in complete recreation.

What to consider with complete recreation

Success stories do exist. Teams using infrastructure provisioning tools like Crossplane, Terraform, and mature GitOps workflows have achieved recreatable applications. But getting there requires stepping back and considering what recreation means from a holistic perspective.

Your application manifests assume that the underlying infrastructure exists, but something must first create that foundation. Many organizations still manage infrastructure provisioning through separate Terraform workflows, creating a gap where recreation often breaks down. While infrastructure provisioning may be mostly automated, unless integrated with your GitOps workflows, you must step away and use another platform to create the infrastructure first.

Recreation means recreating the configuration and access to secrets in the new environment. Your GitOps process needs strategies for safely managing environment-specific values, API keys, and certificates.

Teams can easily recreate applications but can’t recreate data the same way. You need strategies for database backups, data replication, or accepting that data restoration happens separately from application recreation.

External services, APIs, or legacy systems your applications depend on often fall outside what GitOps can recreate. Your recreation strategy needs to account for these dependencies, whether through service discovery, configuration updates, or fallback mechanisms. Additionally, can your target environment support the infrastructure you rely on? Not all cloud services are available in every region, especially during disasters.

70% of high-performers have achieved confidence in their recreation capabilities, and have worked through these considerations. They prove that complete recreation is possible and likely find it worthwhile, but it requires treating it as a comprehensive system design challenge rather than just putting YAML in Git.

The path forward

While the journey from partial to complete recreation involves discovering complexities you didn’t know existed, 70% of high-performing teams that achieved this capability prove it’s possible and worthwhile.

The key is treating recreation as a systematic challenge rather than an afterthought. Whether you’re just starting your GitOps journey or working through the complexities that come with maturity, understanding what complete recreation entails helps you make informed decisions about where to invest your efforts.

For more insights into how teams across different maturity levels approach GitOps and application recreation, download our complete State of GitOps report to see the full research findings and implementation patterns.

Happy deployments!

Related posts