From a simple CLI PaaS to a unified DevOps Platform (2020 → 2026)

TL;DR

Qovery started in 2020 as a simple CLI-based PaaS to help developers deploy faster.

As teams scaled, abstraction stopped working. Kubernetes became the standard, and DevOps teams needed control, predictability, and leverage - not more magic.

Between 2021 and 2023, Qovery embraced Kubernetes and Helm as first-class primitives, focusing on standardizing application lifecycle without forcing teams to rebuild platform glue.

In 2024-2025, Qovery went beyond Kubernetes deployments by introducing Lifecycle Jobs and Terraform deployments, enabling teams to orchestrate applications, infrastructure, and operational workflows under a single lifecycle model.

In 2025, Qovery expanded horizontally into Observability, Security, and Cost Optimization, increasingly powered by AI, with a clear goal: reduce operational toil while keeping the control plane explicit and auditable.

Today, Qovery powers millions deployments per year, runs on thousands Kubernetes clusters, and is trusted by hundreds companies as their DevOps Automation Platform -giving Platform Teams a single control plane to scale autonomy without increasing operational burden.

Through multiple interfaces (UI, CLI, API, Terraform Provider, MCP), Qovery lets Platform Teams build their own internal platforms on top, giving software teams autonomy without losing control.

Qovery [..] is one unified place to manage your infrastructure and its lifecycle - ideal for DevOps teams that value their time and want to maximize software team autonomy without losing control.

----

‍

On January 6th, 2026, Qovery will officially turn six years old.

When we started in early 2020, Qovery was a CLI. The ambition was intentionally narrow: help individual developers deploy applications fast, without having to become infrastructure experts.

Six years later, the platform looks very different.

Today, Qovery is used by DevOps and Platform Engineering teams at companies like Alan, GetSafe, and Talkspace to ship software reliably at scale. This article is a retrospective, an attempt to explain how and why Qovery evolved - from a simple PaaS to a DevOps Automation Platform designed to help DevOps teams become effective Platform Teams and give autonomy to software teams without losing control.

The original problem: speed versus responsibility

If you operate production, you live between two forces:

Software engineers want:

• fast feedback,
• fast deploys,
• minimal friction between code and runtime.

DevOps / Platform engineers are accountable for:

• stability,
• predictable rollouts,
• security and compliance,
• cost control,
• performance and incident response.

At small scale, you can keep things “simple” with a few scripts and conventions. At real scale, that falls apart. Tooling fragments, environments drift, and the platform becomes a second product maintained by a few people. In 2020, the default answer was still: PaaS. So we started there.

2020: the “simple PaaS” phase and why it hit a wall

The first shape of Qovery was PaaS-like: “deploy fast, don’t think too much about infra.” It solved one thing very well: developer velocity.

Then reality showed up:

• teams needed multiple environments and consistency,
• network control mattered,
• cost visibility stopped being optional,
• Kubernetes became the standard runtime for serious workloads.

The problem with pure abstraction is that it scales until it doesn’t. At some point, DevOps teams stop adopting tools that take decisions away or make production behavior harder to reason about. That led to the first hard pivot: Stop hiding infrastructure. Start giving teams leverage over it.

2021-2023: embracing Kubernetes

Kubernetes moved from a trend to the default application execution layer. But “embrace Kubernetes” can mean two very different things:

1. expose raw Kubernetes and let every team rebuild the same glue
2. offer a platform layer that standardizes the boring parts and keeps control explicit

Qovery moved toward option (2).

By late 2023, the direction was clear for us: Kubernetes-native deployments needed to be first-class, and teams needed a clean integration model rather than a black box.

Helm as a control boundary

A major milestone was Helm integration. Not because Helm is new, but because it provides a realistic boundary for platform teams: “this is how apps are packaged, configured, upgraded, and rolled back.”

In December 2023, Qovery Helm native support work progressed quickly:

• repository management and service page support,
• ability to deploy other versions and override values,
• and a key usability piece: environment variable replacement via macros (qovery.env.<variable_name>) inside charts.

This matters for platform engineering because it provides consistent application lifecycle across environments without custom scripting per repo.

“Less glue” as a product principle

As Helm matured, we kept attacking the same pain: teams shouldn’t have to learn internal Qovery-only concepts just to deploy a chart.

In April 2024, Qovery introduced automatic injection of required labels/annotations for Helm deployments through an admission controller-removing the need for manual Qovery macros for configuration.

This is the kind of detail that sounds minor until you run platform adoption at scale:

• fewer “special rules” to teach,
• fewer chart forks,
• fewer hidden conventions.

Kubernetes support wasn’t the destination. It was the base.

2024-2025: going beyond Kubernetes deployments with agnostic capabilities

By 2024, most teams using Qovery in production had a Kubernetes story. But another limitation became obvious:

Not everything belongs in Kubernetes. Production systems include:

• managed services (RDS, queues, buckets),
• IAM resources and policies,
• one-off operations (migrations, seeding),
• infra that must exist before apps start.

If you deploy apps with one tool and provision infrastructure with another (Terraform in CI, custom scripts, separate workflows), you reintroduce fragmentation. You end up with multiple control planes and implicit dependencies.

So in 2024-2025, Qovery expanded deliberately beyond “Kubernetes deployments” into agnostic deployment capabilities anchored around two primitives: Lifecycle Jobs and Terraform deployments.

Lifecycle Jobs: making operations first-class

Lifecycle Jobs are Kubernetes jobs triggered by environment lifecycle events (deploy, stop, delete).

That sounds simple, but the important part is what it unlocks:

• run DB migrations or seeding when an environment deploys, not “whenever someone remembers”
• create external resources not natively managed by Qovery, then inject outputs back into the environment as variables (very very powerful!)
• make operational steps observable and governed, instead of hidden inside CI scripts

Our docs describe how lifecycle jobs can run on events and inject outputs (e.g., a Terraform-created DB URI) into services inside the same environment.

And the product kept investing in the ergonomics:

• allowing a raw Dockerfile to be injected for Lifecycle Jobs directly from the UI (so you don’t have to commit boilerplate Dockerfiles into repos), and improving selection flows around Helm and container versions.

It's all about reducing the friction that prevents platform patterns from being adopted.

Terraform deployments: unify infrastructure lifecycle with environment lifecycle

The other key step was turning Infrastructure-as-Code execution into something the platform can orchestrate.

The Qovery Terraform integration is explicit:

• Terraform manifests/templates can be deployed with Qovery,
• and the execution is handled via Lifecycle Jobs to manage cloud resource lifecycle.

In practice, this means:

• Terraform runs in the same lifecycle model as your environment
• outputs can be captured and injected into services (e.g., connection strings)
• create/destroy can be tied to environment creation/deletion, which is exactly how preview/staging environments should behave

In August 2024, Qovery introduced templates for Terraform deployments to make this setup easier (pre-filled Dockerfile, triggers, commands, resources).

This is the inflection point: Qovery stopped being “a Kubernetes deployment platform” and started becoming a DevOps platform with unified control over infrastructure workflows.

What “agnostic deployments” really means here

When we say “agnostic,” we don’t mean “abstract everything.” We mean:

• Kubernetes workloads (Git apps, containers, Helm)
• operational workflows (Lifecycle Jobs)
• infrastructure provisioning (Terraform / CloudFormation / Pulumi too)
• ordered execution and dependencies (deployment pipelines/stages)

…all described and operated in one place, under one model.

That’s what platform teams actually need: a single operational truth, not another tool to integrate.

2025: the platform expands horizontally - Observe, Secure, Optimize (powered by AI)

Once deployments and infrastructure lifecycle are unified, the next fragmentation is always the same:

• observability lives elsewhere,
• security context is split across tools,
• cost signals arrive late and disconnected from decisions.

In 2025, Qovery started pushing these domains into the platform experience.

Observability: developer-friendly, 1-click, integrated

Qovery introduced Observe and progressively opened access in September 2025.

The roadmap changelog explicitly frames the product direction:

• “1-click setup,”
• “zero maintenance,”
• “data stays in your infrastructure,”
• correlated infrastructure + application events,
• designed to be usable by software engineers for troubleshooting.

The core idea is not “replace every tool you have.” It’s: shorten MTTR by attaching context (deployments/environments) to signals.

Security and cost optimization as platform concerns

Security and cost aren’t late-stage tasks. They are constraints that should shape how environments are created, deployed, and operated.

By late 2025, Qovery’s releases increasingly tie those concerns to platform workflows (SSO, approvals, auditability, platform policies). For example, the Nov 2025 changelog mentions improved security with OIDC/SAML and frames Copilot with role-based approval and “zero data leakage.”

DevOps AI Copilot

In November 2025, Qovery announced DevOps AI Copilot: an AI assistant that translates intent into automated infrastructure tasks, with specialized agents and role-based approval.

This aligns with what DevOps teams actually need in 2026:

• fewer dashboards to babysit,
• fewer recurring manual actions,
• more automation tied to explicit policy and approvals.

The philosophy, now in one sentence

By the end of 2025, the Qovery thesis is the opposite of “DevOps as a bottleneck”:

Give software teams autonomy by making the platform safe by default, and give DevOps teams control without turning them into full-time tool maintainers.

That’s what we’re focused on in 2026:

• deeper native integrations across observability, security, and cost optimization,
• powered by AI where it reduces toil and improves response time,
• while keeping the control plane explicit and auditable.

Our goal is simple for Qovery

One unified place to manage your infrastructure and its lifecycle - ideal for DevOps teams that value their time and want to maximize software team autonomy without losing control.

Interfaces that let Platform Teams build on top

One last piece matters if you’re building a real internal platform: interfaces.

Qovery is not designed to be used only through a UI. Every capability is exposed through multiple interfaces:

• Web UI for day-to-day operations,
• CLI for scripting and automation,
• Public API for deep integration,
• Terraform Provider for declarative workflows,
• MCP Server for agent-based and AI-driven interactions.

It allows Platform Teams to build on top of Qovery instead of working around it.

Some teams use the UI directly, others hide it completely.

For example:

• Alan built its own internal developer interface on top of the Qovery API and relies heavily on the Terraform Provider to integrate application and environment lifecycle into their broader infrastructure workflows.
• Hyperline uses the Qovery API as part of its product to automatically provision dedicated domains and infrastructure for its customers.

In these cases, Qovery is the control plane the platform team composes with their own systems.

This flexibility becomes even more important as automation increases: whether an action comes from a UI, a Terraform plan, a CLI command, an internal portal, or an AI agent, the underlying platform remains consistent, auditable, and governed.

Closing

Six years ago, Qovery was a CLI MVP and a simple idea: reduce deployment friction.

It grew into a Kubernetes-native platform, then into a broader DevOps platform by addressing the parts that consistently break at scale:

• environment lifecycle
• operational workflows
• infrastructure provisioning
• and now runtime signals (Observe), constraints (Secure), and economics (Optimize), increasingly assisted by AI

If you’re a DevOps or Platform Engineer and you’ve built parts of an internal platform yourself, this evolution should feel familiar - because it was shaped by the same problems you already solve.