Skip to main content

Overview

The Qovery CLI (Command Line Interface) enables you to interact with Qovery directly from your terminal. Deploy applications, manage environments, stream logs, and more - all without leaving your command line.

Installation

To download and install Qovery CLI on any Linux distribution:
The install script does not verify the binary’s integrity. For security-sensitive environments, use the Manual tab to download a pinned release and verify its checksum against the official checksums.txt published with each release.

Verify Installation

Authentication

Before using the CLI, you need to authenticate:
This will open a browser window for authentication. Once completed, you’ll be ready to use the CLI.

API Token Authentication

You can also authenticate using an API token:
Generate an API token from the Qovery Console.

Configuration

The CLI stores configuration in ~/.qovery/context.json. You can manage multiple contexts for different organizations or clusters.

Set Default Context

List Contexts

Watching Operations

Most deployment commands accept the --watch (-w) flag to wait until the targeted services finish and report their final status. The command exits with a non-zero status if a watched service fails, is canceled, ends in an unexpected state, or no longer exists — useful in CI/CD pipelines. By default, a watch stops after 1 hour and exits with an error if the services have not finished. To wait longer (for example for long builds or Terraform runs), set the QOVERY_CLI_WATCH_TIMEOUT environment variable to a Go duration such as 2h:

Blueprint Databases

Databases created from a database blueprint are Terraform services, and the CLI supports them like native databases.

List Blueprint Databases

qovery database list lists the blueprint databases of the current environment together with the native databases. Blueprint databases appear with the type Blueprint database, and the output shows their status, host, and port:
Add --show-credentials to display the login and password, as for native databases. If the credentials are not available (the database is not deployed yet, or you are not allowed to read them), only the host and port are shown. With --json, blueprint databases are included in the output with the same fields as native databases. The login and password fields are only filled when --show-credentials is set.

Port-Forward to a Blueprint Database

qovery port-forward accepts the Console URL of a Terraform service, such as a blueprint database. Pass the URL of the service followed by the ports to forward, in the local_port:remote_port format:
If the service ID in the URL does not exist in the environment, the command fails with a not found in environment error.

Blueprints

Point a Blueprint at a Newer Major Version

qovery blueprint upgrade-major points a blueprint service at the latest tag of a newer major version, for example PostgreSQL 14 to 18. It is built for AWS RDS PostgreSQL databases: Qovery checks the version the database runs and handles the upgrade end to end. Other blueprint services are accepted, but Qovery does not check that their new major can be applied safely, so review that template’s upgrade notes first. Run it without --major to list the newer majors and what moving to each one would do:
Then pick a major:
The command shows what will happen and asks for confirmation (--yes or -y skips it), then updates the blueprint and deploys it. Add --watch (-w) to follow the deployment.
  • Relabel: the service already runs that major, for example a database upgraded with an AWS Blue/Green deployment. Only Qovery’s records change; the service is not touched. Qovery detects this for AWS RDS databases only.
  • Upgrade: the service runs an older major.
    • For an AWS RDS PostgreSQL database, the deployment upgrades it in place and takes it offline while AWS upgrades it. Use this for non-production databases.
    • For a production database, upgrade with an AWS Blue/Green deployment first, then run the command: it only relabels the blueprint.
    • Other blueprints always take this path; what happens then depends on their template’s own upgrade behavior.
  • Not supported: the move is refused and the command explains why, for example a lower major than the one running. If the command reports an unknown switch mode, update the Qovery CLI.
See Moving to a newer major version for details.

Environment Variables

Override a Variable That Already Exists at a Higher Scope

The env create commands (application, container, cronjob, environment, helm, lifecycle) accept an --override-if-exists flag. By default, creating a variable whose key already exists at a higher scope fails with a conflict. With the flag set, Qovery creates an override of that variable at the target scope instead:

Key Features

Deploy Applications

Deploy and redeploy applications instantly from the terminal

Environment Management

Create, update, and manage environments

Live Logs

Stream real-time logs from your applications

Shell Access

Execute commands directly in running containers

Quick Start

List Projects

List Environments

Deploy an Application

View Logs

Next Steps

CLI Commands

Explore all available commands and examples

Your entire infrastructure, one terminal command away

Deploy, manage, and monitor without ever opening a Kubernetes dashboard. Qovery turns complex cluster operations into simple CLI calls.

Get started free →