Case Study: Scaling Aryon Security’s Database Deployments with the Atlas Kubernetes Operator

Company Background

Aryon Security is a preventative cloud security platform that enforces security policies at the point of deployment, stopping misconfigurations before they ever reach production rather than flagging them after the fact. Acting as a source-agnostic gatekeeper across AWS, Azure, and GCP, Aryon applies the same protection whether infrastructure is provisioned through IaC, ClickOps, or third-party providers, letting security and platform teams define a policy once and ensure only compliant infrastructure is ever deployed.

Getting Ahead of Migration Struggles

Omri Tcherner joined Aryon when it was little more than a handful of employees and an idea. He came in having experienced the pain schema migrations can cause from a previous role and made an important decision. "I had very bad experiences with schema migrations, so my goal for us was to do them correctly from day one," Omri said. Rather than let schema management become a pain point once the company scaled, they treated it as something to get right from the very start.

Atlas was one of the first tools Omri researched while setting up Aryon's stack. It was easy to onboard and worked for their planned setup, so Aryon adopted it before it even had a single production workload to migrate. 18 months later, it's still the only tool the company has used for the job. "We never thought about looking elsewhere because it's done exactly what we need it to do since the beginning," Omri said.

Rolling the Kubernetes Operator Out to Five Environments

While the core tool met all of Aryon's initial needs, their workflow scaled further when they moved from basic Helm charts to a more declarative architecture. "We used Helm charts for deployment in our original setup, but when Atlas’s Kubernetes Operator came out, we were one of the first to jump on the chance to use it," Omri said. The Kubernetes Operator opens the door to managing your database schemas with Atlas from within your Kubernetes cluster. This allows developers to focus on the desired state of their cluster and let Kubernetes handle the complexities of how to get there. As early adopters running a multi-environment setup, Omri and the team worked closely with Atlas, sharing real-world feedback to help catch edge cases in the newly released feature.

Today, that workflow is woven directly into Aryon's engineering pipeline. Day to day, engineers define their schema in their application code, and Atlas generates versioned migration files directly from it. Before any code is merged to dev, Atlas's CI checks catch non-linear migration histories before they can compromise the database.

Once a pull request is approved, the Operator takes over for deployment. Aryon runs a separate instance of the Operator across five distinct environments: dev, staging, an integration testing cluster, and two production regions. The Operator treats database migrations like any other declarative Kubernetes resource, applying them automatically during deployment without a single engineer needing to run anything by hand.

This workflow extends all the way down to local machines. Aryon's backend and research teams spin up local Kubernetes clusters managed by the same Operator setup. For the research team writing Aryon's security policies, that consistency matters: to validate a new policy, they deploy Aryon's full stack locally, let the Operator migrate the database, and test their work against live cloud sandboxes.

The Outcome

Now, the Kubernetes Operator has become invisible infrastructure for Aryon. Schema changes just ship as part of every deployment, in every environment, without engineers thinking about them.

• A Frictionless Developer Experience. Schema management stays out of the engineers' way entirely. With their internal setup, new engineers run a single command that generates protobufs and Atlas migrations together. "It connects to our models and people don't even have to think about migrations, they just happen," Omri said.
• Consistency Across Teams and Environments. The same migration workflow scales across the whole organization. Two backend teams and a research team all follow the same process, while the Kubernetes Operator applies it uniformly across five environments as well as local development.
• Layered Testing and Guardrails. Atlas's checks run in CI to catch nonlinear migration history before it merges, and Aryon also uses Atlas to run randomized migrations inside its unit tests, adding another layer of confidence before schema changes ship.
• Responsive Support When It Matters. When a CI misconfiguration once pushed a bad migration toward production, Omri worked through the fix directly with the Atlas team over Slack. "Every time we need anyone from the team, they're always available to help," he said.

Looking ahead, Aryon is continuing its track record as an early adopter by serving as one of the frontrunners for Atlas's new ad-hoc data migration feature. "That’s something we’re really looking forward to," says Omri. "It will give us another layer of interaction with the product that will further improve our workflow."

At the same time, Aryon is preparing to expand beyond its lean PostgreSQL setup by adding ClickHouse to its architecture. Atlas’s native support for ClickHouse means the team can seamlessly bring another database engine under the exact same automated Operator workflow without adding operational complexity or breaking stride.

Getting Started

If you're running Kubernetes across multiple environments and want schema migrations to deploy automatically and safely as part of your existing rollout process, the Atlas Kubernetes Operator can fold database changes into the same pipeline you already use to ship everything else.

If your team is trying to build good migration habits before schema management becomes a bottleneck, or needs one consistent workflow across dev, staging, and multiple production regions, Atlas is the solution for you.