Deploy Ory on Kubernetes with enterprise-grade Helm charts built with autoscaling, observability, and continuous security hardening out of the box.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
Deploying an Identity and Access Management (IAM) platform on Kubernetes can be challenging. That’s why Ory provides Enterprise Helm Charts to help you address the operational headaches.
That is the problem Ory Enterprise Helm charts are built to solve. Once Ory is running in your own Kubernetes environment, the chart becomes part of your operating model. It defines in a declarative way how things should be deployed on Kubernetes, such as how services should scale, expose runtime data, recover from failure.
The difference between “it deploys” and “it operates well” is where most of the real work lives.
Ory Enterprise Helm charts package that work into production-oriented deployment defaults for teams running Ory themselves.
Ory has long provided open source Helm charts that help teams deploy Ory components on Kubernetes. Those charts are useful for getting started and for teams that want to make every operational decision on their own.
But production environments need more than a working install. They need replica strategies, health checks, autoscaling behavior, load balancing, as well as monitoring configuration that sets the enterprise up for observability – runtime visibility that provides a way to expose logs, metrics, and traces so the systems around Kubernetes can actually understand what is happening.
That is where Enterprise Helm charts change the value proposition. Not only do our enterprise charts provide a cleaner way to install Ory, they are a supported operational layer for running Ory on Kubernetes with better defaults, clearer runtime behavior, and less custom infrastructure work for your team to maintain.
In a production deployment, every default matters. How many replicas should a component run? How should traffic be routed so Ory components stay available during spikes, rollouts, and node failures? Are readiness and liveness checks configured? Are services positioned so one node failure does not take out the whole deployment? Is the database treated as an external dependency, where managed Postgres or CockroachDB can be operated properly?
Ory Enterprise Helm charts include production-oriented defaults so teams do not have to rediscover the same baseline architecture from scratch.
These operational considerations are far from trivial since they are the fundamental elements that determine a system's availability, resilience, and effectiveness in incident response. That means your team spends less time turning a basic chart into a production chart and more time operating Ory in a way that matches your infrastructure and risk requirements.
Generic autoscaling is easy to configure poorly. A chart can expose CPU and memory settings, but that does not mean those settings reflect how the software behaves under real load. Some services are CPU-bound. Others may be more sensitive to memory. Scaling on the wrong signal can mean the system reacts too late, reacts unnecessarily, or fails to react at all.
Ory Enterprise Helm charts apply component-aware operational guidance. This means providing scaling definitions to best match the operating model of each component individually across Ory’s product ecosystem: Kratos,.
The charts are designed around the runtime profile of Ory components so autoscaling decisions start from how the software actually operates, not from generic Kubernetes assumptions. You can still tune the configuration for your environment. The difference is that you are tuning from a better starting point.
Kubernetes spreads your pods on a best-effort basis, and left alone it will place several replicas of the same service on one machine when nothing tells it otherwise. That looks fine right up until that machine fails and takes those replicas down with it.
The Ory enterprise Helm charts operational best practices for deploying the workload on the nodes of the clusters to maximize to optimize operational resiliency.
Placement also matters during a traffic peak. Even when a cluster has enough total capacity, uneven scheduling can create an invisible limit on a single node, and a deployment with several replicas can still behave poorly if those replicas are stacked rather than spread. The charts ship the operational toolbox for the recommended placement patterns, and leave you room to adjust the rules for your own topology, capacity model, and cluster design.
The most important operational question is not only “is Ory running?” It is “can your team understand what Ory is doing while it runs?”
Production teams already have monitoring stacks. They may use Prometheus, Grafana, Jaeger, OpenTelemetry-compatible systems, log pipelines, metrics platforms, or internal observability tooling. The Helm charts makes Ory’s runtime data available to them in a predictable way.
Ory’s Enterprise Helm charts include monitoring and observability configuration so teams can more easily collect and consume the data Ory components produce: logs, metrics, and traces.
The charts make that data easier to expose and integrate. Your existing observability layer can still do the analysis, alerting, visualization, and retention. The value of the chart is that Ory is deployed in a way that makes those signals available from the start.
Monitoring data allows you to better understand what’s going on in the platform, as well as with the applications themselves (e.g. workload metrics such as performance, usage, increase of consumption). This can also support A/B testing, and performance tracking of your applications and services.
In Kubernetes, security risk often comes from how software is deployed and operated. For identity infrastructure, that means secrets must be handled carefully, services should expose only what they need to expose, runtime behavior must be observable, and failure should be contained instead of cascading across the deployment.
Ory's Enterprise Helm charts ship with security best practices pre-configured. We continuously scan the Kubernetes workloads with security tools, read what the reports flag, and correct the insecure policies at the chart level. When a tool surfaces a weak default, the Ory team fixes it in the chart and our enterprise customers pick up the change by updating their helm chart version.
Ory maintains this hardening continuously, so your team doesn't have to – freeing up your resources and leaves security to the subject matter experts.
The point of Enterprise Helm charts is not that Helm is complicated. The point is that running identity infrastructure well is complicated. It doesn’t have to be.
A production identity system needs to scale at the right time, expose the right signals, survive common infrastructure failures, and behave predictably when teams are under pressure. Those qualities do not appear just because software is installed on Kubernetes. They have to be designed into the deployment.
Ory Enterprise Helm charts bring those decisions closer to the product. They package Ory’s operational knowledge into a supported deployment layer so teams can spend less time guessing, less time maintaining custom hardening, and less time discovering production lessons during incidents.
For teams running Ory on Kubernetes, that is the value: a deployment model that is easier to operate, easier to observe, easier to scale, and better aligned with how Ory is meant to run in production.
If you are already self-hosting Ory, the best next step is to review your current deployment model before changing it.
Look at how your Ory components are deployed today, how they scale, where runtime data flows, what monitoring tools consume that data, and how your cluster handles node failure or traffic peaks. That context should shape the migration.
Rather than assuming every cluster follows a single pattern, the Enterprise Helm charts are designed to adapt to the complexities of actual production environments.
If you are migrating from the open source charts or replacing internally maintained charts, contact your account manager or reach the Ory team through support.ory.com. We can help review your setup and map the migration to the way your architecture and systems actually operate.
Not an Ory enterprise customer? Contact us to learn more how your business scales more efficiently and securely with Ory’s modern approach to identity.
