Inside Qovery’s security architecture: how we secure your cloud & Kubernetes infrastructure

At Qovery, we always treated Security as a central pillar of our engineering choices. From encryption to auditability, from secrets to updates, every component works to ensure we provide you with the highest standards, in our product, and for your applications.

As they say, show, don’t tell, so let’s dig deeper into how Qovery backs our claims.

Qovery in a nutshell

Qovery is a DevOps automation platform. It is meant to bring you and your developers the best properties of modern infrastructure (reliability, scalibility, observability, security, flexibility) while saving you the operational overhead that generally comes with it.

To provide this automation, you define your desired state in the Qovery Control Plane (SaaS product) using your favorite client (CLI, Terraform, AI, API, Web Console…), and the Control Plane defines the tasks required to reach this state.

The Qovery engines actually execute those tasks and ensure that your Kubernetes Clusters are deployed, configured, updated, and host the desired applications.

Qovery was founded by infrastructure experts, well aware that this position holds great responsibilities, and must deserve your trust.

To earn your trust, we make Qovery transparent where it matters, your secrets protected, and your infrastructure resilient and standards-compatible, even without or after Qovery.

In short, Qovery bridges the gap between your developers and your IaaS subscription or your On-Prem stack.

Qovery architecture

Here is a high-level overview of Qovery’s components and their immediate environment.

Qovery’s components can be split into 4 categories:

• The front-ends including the Web UI (Console), the CLI, the Terraform provider, and the AI-Assistant (Copilot).
• The back-end that executes all business rules, stores configuration data, and prepare deployment jobs.
• The engines in charge of actually executing deployment jobs, whether by calling Cloud Service Providers APIs (Infra Engines) or building apps and piloting Kubernetes clusters (Env Engines). Infra or Env, it’s all the same code: the Qovery Engine.
• The agents ensuring your services’ DNS records and TLS certificates are set up, and forwarding monitoring data to the back-end upon request

The components named [Qovery Backend], [Qovery Monitoring], [Qovery AI Copilot], [Infra Engines], and [Managed Env Engines] in the diagram are currently hosted by AWS, in region [us-east-2].

The communication flow is as follows:

You run it, you own it

One of the core tenets of Qovery is to avoid vendor lock-in.

Your applications, your infrastructure, your data, your devices, they’re yours, whether Qovery is here or not.

We deploy, you run

Once a service is deployed by Qovery, it is set-up once and for all. Qovery services are not needed to keep it running.

Should Qovery become unavailable, only your deployment capability is impacted, not your operations.

Federated identities only

Access to Qovery is made using Auth0 (Okta), and only allows you to connect through your favorite Identity Provider.

Whether it’s Google, GitHub, GitLab, BitBucket, Microsoft, or even your own SAML or OIDC IdP, you remain in control of your password and authentication policies. Qovery just follows your rules.

There’s no such thing as a Qovery password.

Industry standards

Whatever your favorite flavor of Kubernetes, Qovery relies on standard K8s API calls, without adding a proprietary layer, or mandatory agent.

The engines rely on Terraform, Helm, and Kubectl, not some self-made black box.

This means that Qovery can be added, after the fact, to your current infrastructure, and that your infrastructure keeps on running even if you stop using Qovery.

Open-source that matters

Every Qovery-built software component intended to run on your infrastructure, your devices, or in your web browser is Open Source, freely available on GitHub.

You can audit the source code, dependencies, Terraform files, and Helm charts as you see fit.

🫵 Why it matters to you

Come as you are

If you already use standard IaC and/or containerization tools, you can leverage what you have directly in Qovery. No need to rewrite, adapt or migrate.

Once your setup is running, you only need Qovery to keep your deployments flow. You can still monitor, query, observe your Kubernetes Cluster as you wish, with standard tools.

Should I stay or should I go

Even if Qovery were to experience downtime, you will have no impact on your running services. Even automatic TLS certificates renewal will keep working.

And should you decide to stop using Qovery, your cluster will stay the same, and you’re left with reusable blueprints as if you did it yourself without Qovery.

How the data flows

Unique encryption keys

Qovery lives in a central place in your information system, between your source code and your infrastructure. As such, Qovery has privileged access to these vital assets. Here’s how we keep them safe.

We use AWS KMS to provide us with an HSM-generated cryptographic key, and allow us to perform key rotation at scale safely. Access to this key is tightly restricted.

Each customer’s organization gets its own, unique, PBKDF encryption key.

Our database is hosted on AWS RDS with AES 256 encryption enabled.

‍
🫵 Why it matters to you

Get off my lawn

We use different encryption keys for each customer, so even if despite our best efforts, another customer compromises Qovery, they have no way to decrypt your keys, limiting the impact of lateral movements.

Hard as rock

As our database relies on AES encrypted volumes, even physical access to our servers, hosted by AWS, cannot grant access to your data.

Secret mission

Each Qovery deployment job requires only a limited subset of an organization’s secrets. Qovery knows what’s needed, and provides the engines with the strict necessary to do their job.

On cloud providers where such a technology is available, Qovery uses short-lived tokens to connect to your IaaS tenant, e.g. using STS for AWS.

Your logs, your certificates, right where they belong

Qovery allows you to monitor your deployments, but also your apps, and go even beyond with our Observability module.

While Qovery provides you with a live, seamless observability experience, your application logs, usage data and metrics are never stored in our systems. They remain on your infrastructure, and are pulled, as needed, directly there. We don’t keep a copy., we don’t store your logs, usage data or metrics.

Let’s focus on a subset of the architecture diagram.

Your deployed services send telemetry locally, to the Qovery Agent, which in turn can forward the relevant data, through gRPC calls to the Back-end, to be delivered in the web console for example. No copy is kept on Qovery’s systems.

To fully grasp how this works, we need to zoom in a bit more on what is called the Qovery Agent until now. It is not a single software component, not even a single container. It is a collection of apps running inside the `qovery` Kubernetes namespace, within your cluster.

In this namespace lives a Loki / Promtail / Thanos / Prometheus stack that is queried through Qovery’s backend when using the Service Logs, Monitoring or Alerting features of Qovery, but also instances of cert-manager or External-DNS

The local cert-manager means that your certificates are based on private keys that never leave your infrastructure, giving no chance to mishandling or interception.

‍
🫵 Why it matters to you

Waterproof

A misconfiguration or development error can result in unwanted information being logged by an application. Should this happen to you, Qovery would be none the wiser, and you can act accordingly freely, on your data, in your servers, so an error does not turn into a data leak.

With great power…

Qovery grants you fine-grain access control over your resources with our Role-Based Access Control (RBAC) system.

We have defined 4 built-in roles: Admin, Billing, DevOps, and Viewer. You can see what access they are granted in the docs, but you can define custom roles too.

Each custom role can be granted permissions at different levels:

• At cluster level
  
  • For all clusters
  • For each defined cluster independently

• At project level
  
  • For each defined project independently
  • For environment types (production, staging, development or preview) within a given project

With our SSO module, you can also automatically map your IdP groups to roles, either built-in or custom, allowing you centrally manage who gains access to what, using your usual administration tools and process.

👉 Now that you defined “who can do what”, you probably wonder “who did what, and when”.

That’s where our Audit Log feature comes to the rescue. You can access it from a global, organization-wide standpoint, or contextually, from a given Cluster, Project, Service, Environment, or Service standpoint.

Every action is logged in an immutable database, with rich details covering the who, the what, the when, and even the how of every change made to your infrastructure.

Qovery team’s support operations are logged too, so nothing can escape your scrutiny.

‍
🫵 Why it matters to you

Dot the i's and cross the t's

If your infrastructure behaves suspiciously, you will want to know the truth. Qovery lays bare, before your eyes, every action, every change, in order to assist with your investigation.

Personal data, no thank you.

The Qovery-built components (the green blocks in the architecture diagram) stores the strict minimum of Personally Identifiable Information (PII):

• A pseudonymized user identifier (User ID)
• IP addresses (in logs)

Note that, depending on your usage of Qovery, there may be other PII involved, e.g. if you include an email address as the value of an environment variable, but we strongly recommend no doing so, and will not treat “free text” elements of your organization as PII.

IP addresses appear in logs, and are kept for security & compliance reasons, even if you delete your organization.

User ID are pseudonymized only as long as we can connect them to other PII like your name and email address. As soon as these are deleted, the User ID can be considered as anonymized fully, as it is not reversible to a name or email address.

👌 Your name and email address are actually stored in our delegated authentication service: Auth0

The Qovery backend queries Auth0 for names and emails, to be able to display names in the console, or to send you email notifications, so these are processed by Qovery **but never stored** in our product’s database.

We do, however, share PII with some of our sub-processors (the blue blocks in the architecture diagram), as necessary to comply with our legal obligations (billing, etc.) and to provide our services. We make sure that all the relevant legal measures are in place to frame the transfer of such PII to these sub-processors, and ensure you can exercise your rights to privacy.

Continuous security

Qovery adheres to industry best-practices to ensure that we continuously maintain and improve the security level of our product.

• Our source code management system imposes review of all changes before deployment
• We track dependencies vulnerabilities on every layer thanks to AWS GuardDuty, Dependabot, Renovate…
• We create backups, and we test the restoration procedure weekly
• We prevent technical debt and outdated libraries, requesting our “on-call” engineer to update all dependencies as part of his weekly chores (weekly rotation)
• We prevent configuration drift by using Infra-as-Code tools, and Cloud Security Posture Management (CSPM) tools, ensuring we apply continuously-updated best practices.

🙌 We use Qovery to deploy Qovery. Every improvement we make to our own infrastructure security is automatically reflected in yours (for the relevant scope).

As we are aware that no technical solution can reasonably claim to be 🙃*100% secure*🙃, we ask the best research teams to try to hack our product on an at-least-yearly basis through penetration testing.

This solid technical foundation is completed with a continuously-improving cybersecurity management system based on risks assessment and treatment, leading to our SOC2 Type 2 certification in October 2025.

Customer-driven future

We are developing new features, and improving the existing ones, to enhance your security and keep deserving your trust.

As a Qovery customer, your inputs are highly valuable, and your impact on our roadmap is real.

Should you wish to discuss risks, features, or integrations, we would be delighted to hear your opinion and inputs.