Why Cybersecurity SaaS Companies Use Plural

If you’re building a security company, you’re in the business of trust. Your customers, who are often security teams themselves, aren’t just buying your software; they’re buying the guarantee that their data will be completely isolated and protected. This isn’t just a feature request. It’s a non-negotiable requirement that locks you into a single-tenancy architecture. 

This architectural decision to adopt single-tenancy, while necessary, has massive downstream consequences. While it gives your customers the peace of mind they need, your engineering team is handed an operational nightmare. We’ve seen this story play out again and again. Companies end up crushed by the complexity of managing hundreds of separate application instances, and their platform teams burn out.

We built Plural to solve this exact problem. It’s made for companies that can’t compromise on security but also can’t afford to have their entire engineering team derailed by infrastructure complexity.

Why You’re Stuck with Single-Tenancy

Let’s be clear about why this is such a big deal. The standard multi-tenant model is a huge web service where all your customers are intermingled. You build walls in the software to keep your customer’s data separate, and for most businesses, this is perfectly fine and highly efficient.

But if you’re selling a security product, you can’t risk a single bug in the application logic. Your customers know this, which is why they want single-tenancy. In the event of a security breach or a critical application failure, the damage is contained entirely within that single tenant’s environment. This provides a powerful assurance to the end customer. 

This customer-driven demand for data segregation isn’t unique to cybersecurity; For what it's worth, I saw this exact pattern play out with a no-code platform I worked with in the past. To be enterprise-ready and give their customers peace of mind, they had to adopt the same single-tenant model.

Why Single-Tenancy Doesn’t Scale

Choosing single-tenancy solves the data isolation problem, but it creates a new, far more insidious one. The math here is brutal. The chance of a failure across your fleet isn’t linear; it’s exponential. As the number of instances grows, the probability of something being broken at any given time is close to 100%. You're not just fighting bugs. You're fighting the randomness baked into any complex system. A cloud provider API might flake out, a node might fail, a network partition might occur. With hundreds of instances, you’re constantly fighting a rising tide of random failures.

This is the point where the tools everyone knows and loves start to fall apart. GitOps tools like ArgoCD and Flux are great, but they weren’t designed to manage thousands of distinct clusters from a single control plane. Push-based CI/CD from a tool like GitHub Actions becomes a flaky mess when you’re trying to push to hundreds of different environments. A single failed pipeline run can block deployments for everyone, and good luck trying to manually restart the right one among hundreds. You hit what we call “toolchain breakage points,” and you’re forced into a painful, expensive re-architecture, all while trying to serve your customers.

The Two Halves of the Problem: YAML and Terraform

When you dig into why this is so hard to solve, it’s because you’re actually dealing with two distinct but deeply intertwined challenges. Most teams only see the first one initially.

First, there’s the YAML problem. This is about managing the Kubernetes-level resources for each tenant: the deployments, services, config maps, and ingress controllers. This is the world of Helm charts and Kubernetes manifests. At scale, this becomes a challenge of managing configuration drift and ensuring that every single one of your hundreds of application instances is running the correct version with the correct parameters. This is the part of the problem that tools like ArgoCD and Flux are meant to solve.

But then there’s the much harder Terraform problem. True single-tenancy often requires that each customer gets their own dedicated cloud infrastructure. We’re talking about a separate VPC, a unique Kubernetes cluster, and a specific set of IAM roles and permissions. This layer is managed by infrastructure-as-code (IaC) tools like Terraform, and it must be provisioned before you can even think about deploying your application’s YAML. For example, you can't deploy an ingress controller (the YAML problem) until the VPC, subnets, and the Kubernetes cluster itself (the Terraform problem) actually exist.

A DIY solution almost always treats these as separate problems, leading to a brittle, two-step process where one team provisions infrastructure with Terraform and another team deploys applications with a GitOps tool. This separation is where errors, delays, and configuration mismatches occur.

The FedRAMP Multiplier

For companies selling to the U.S. government, this already complex picture gets even worse. FedRAMP requirements create a hard, firewalled boundary around the federal environment. You can’t have your normal commercial CI/CD pipeline on GitHub reach in and manage it. This forces you to maintain two completely separate stacks, effectively doubling your operational load and creating silos that prevent best practices from being applied everywhere.

The Solution: One Control Plane for Everything

The only way to handle this sustainably is to treat your entire fleet as one system. You need to solve both the YAML and Terraform problems from the same control plane. That's where pull-based GitOps comes in. We designed Plural to manage two levels of tenancy from one control plane:

1. Application-Level Tenancy: For customers okay with sharing a cluster, we use our GitOps engine to deploy their unique application instance from a Helm chart.
2. Infrastructure-Level Tenancy: For customers needing full isolation, our GitOps engine uses Terraform to provision the entire stack—the VPC, the Kubernetes cluster, the IAM roles—and then deploys the application on top of it.

This is the critical part. We use GitOps for both the application (Helm) and the infrastructure (Terraform). The entire lifecycle, from bare cloud to a running app, is a single, declarative workflow triggered from a single Git commit. This closes the gap between the two halves of the problem, eliminating a major source of errors and operational drag.

The Trap of Building It Yourself

When faced with this problem, a lot of smart engineers think, “We can build that.” But, we’ve seen what that looks like. It usually involves building a custom API on top of an open-source tool like Argo, then bolting on a separate Terraform orchestrator. You end up with a brittle, glued-together system that requires constant care and feeding.

For example, you'd probably have to run a separate ArgoCD instance in every cluster. That means no unified view of your fleet—just hundreds of individual Argo instances to babysit.

The result is always the same: a massive, ongoing engineering effort to maintain a complex internal product that isn’t your actual business. We saw this with one of our clients. They ended up with a huge, burned-out DevOps team, all because they were spending their time maintaining a bespoke platform instead of focusing on their core security mission.

Getting Started without a Massive Migration

If you’re already feeling this pain, the thought of a huge migration is daunting. But it doesn’t have to. Plural is built on open-source standards like Helm and Terraform, and the transition can be surprisingly seamless. We call this “reparenting.” You can take your existing Helm charts and Terraform modules and simply have our deployment engine start managing them. For instance, a team can point Plural at their existing Git repository of Helm charts, and our engine can take over the deployment and management of those releases without requiring any code changes.

This allows for an incremental adoption. You can start by getting the immediate win of a single pane of glass for your entire fleet, stabilizing your operations. Then, over time, you can begin to optimize your architecture to take advantage of the platform’s more advanced features. This pragmatic approach drastically lowers the barrier to entry.

It’s All About Day-Two

The real value of this approach becomes clear after the initial deployment. Managing Day-2 operations (upgrades, security patches, incident response) is where the complexity really crushes you. 

But the challenge at this scale goes beyond just upgrades. Every single change, no matter how small, becomes a high-stakes event. How do you guarantee a change is safe before you fan it out across hundreds of clusters? Manual PR reviews can be a huge bottleneck. The only answer is automation. You need a system that can run integration tests across a representative sample of your fleet to validate a change before it’s merged. This is the next frontier, moving beyond simple CI/CD to true automated validation, and it’s a core part of our roadmap.

Ultimately, choosing single-tenancy is a business requirement for security companies. But you shouldn’t have to sacrifice your engineering culture to meet it. By moving away from a brittle, DIY approach and adopting a platform designed for this specific problem, you can give your customers the trust they demand while allowing your team to focus on what they do best: building a great security product.