The Top 10 Qovery CLI Commands You Must Know
Once you have installed the Qovery CLI, here are 10 Qovery CLI commands you must know - plus a few power tips.
1/ qovery shell
Open a shell session inside a running container
Ideal for debugging or manual inspection in live environments.
Select the right container if the app runs multiple services.
You can even specify the web console URL of your app to connect to it directly.
2/ qovery port-forward
Forward a remote port to your local machine
Use this to connect to internal services like Postgres, Redis, or internal APIs securely.
Qovery handles all auth and routing under the hood.
Same as with the shell, by convenience, you can specify the web console URL to port-forward directly to a specific app.
3/ qovery cluster debug-pod
Launch an ephemeral debug pod in your cluster
This is for platform engineers. It starts a pod with essential tools like kubectl, k9s, curl, and it is excellent for troubleshooting directly inside the cluster.
Requires organization admin permissions.
4/ qovery environment clone
Clone an entire environment in one command
It copies your apps, databases, jobs, and configurations - perfect for setting up preview, staging, or temporary test environments.
Everything is copied and redeployed automatically.
5/ qovery environment deploy
Deploy and control an entire environment
Besides deploying, this command lets you stop, restart, or delete environments.
It’s your environment control panel via CLI.
6/ qovery application env
Manage environment variables and secrets for an app
Set, list, edit, or delete env vars directly from your terminal.
To create an environment variable
Secure by design - no secrets are ever exposed in plaintext.
7/ qovery logs
Stream your application logs in real-time
Useful for both runtime debugging and build output.
You can also fetch logs for jobs and databases.
8/ qovery demo
Spin up a local k3s cluster and play with Qovery
This command sets up Qovery locally using Docker. No external infrastructure needed.
Great for quick testing or internal demos.
9/ qovery auth --headless
Authenticate without using your browser
Useful in headless or remote environments (e.g. CI, SSH sessions, remote VM).
Generates a token-based flow for secure CLI auth.
10/ JSON Output Support: --json
Get structured CLI output for automation and scripting
Any list or info command can be extended with --json to output machine-readable data.
Perfect for scripting workflows or integrating with other tools.
Bonus: qovery service list --markdown
Generate a Markdown-formatted list of your running services
Ideal for CI/CD pipelines and documentation. It outputs service names and their public URLs in Markdown format.
This makes it easy to display or publish the list of active services after deployment (e.g., in a GitHub PR comment, Slack message, or Confluence page).
Wrap Up
The Qovery CLI gives users full control over their applications and infrastructure from the terminal - without dealing with the complexity of Cloud and Kubernetes. Whether you're spinning up environments, debugging issues, or automating workflows, these commands help you move faster and stay in control.
Every command respects Qovery’s permission model, making it safe for teams of any size. If you haven't tried the CLI yet, install it and start integrating it into your workflows:
Want more advanced tips, scripting examples, or automation use cases? Let us know - we’ll cover them in a follow-up.
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)