# AX Check: qovery.com Checked 2026-10-19. Qovery's docs and quickstart let agents install and deploy fast. 21 of 23 checklist items passed, with install commands, CLI, SDKs and an MCP server all documented; pricing is posted as plain text with clear units. ## Onboarding needs a login ## Coding sessions Of three independent sessions, one did not complete. Of the other two, one quoted exact tier prices and overage terms straight from the pricing page; the other recalled rough figures from memory and flagged them as unverified. ### DeepSeek V4.1 Flash [View public run](https://agents.withgauge.com/p/runs/de33e315-02be-4061-a08f-379136de312a) · [Read transcript](https://www.ax-check.com/qovery.com/sessions/deepseek.json) #### End-to-end onboarding - **End-to-end onboarding not demonstrated**: The agent never obtained a real Qovery API token during the session. It wrote a Node.js script requiring QOVERY_API_TOKEN and designed a --dry-run mode (simulated calls, no network) because no credential existed in the environment. The transcript ends mid dry-run execution with no evidence of a live token being generated or an authenticated call succeeding against api.qovery.com. Event 9: ```text no qovery env vars ``` Event 116: ```text [dry-run] GET /organization Failed: No organization found for this API token. ``` Event 111: ```text Auth: create an API token in the Qovery Console -> * Organization Settings -> API Tokens, then: * export QOVERY_API_TOKEN="..." ``` #### Hallucinated URLs - **Guessed sample-app repo name before finding the real one**: The agent tried a guessed GitHub repo name for a Qovery example app that does not exist, before discovering the correct repo via the GitHub API. This was self-corrected within the same turn and did not block progress, so it is noted as a minor guess rather than a blocking hallucination. Event 93: ```text Qovery/simple-node-app -> 404 ``` #### Blockers - **No API credential available, so the example could only run in dry-run/simulated mode**: The sandbox had no Qovery API token (env scan found none), and the test setup gave the agent no way to generate one through a self-service signup flow in-session. This is a test-environment/credential limitation, not a product defect: Qovery's documented workflow requires logging into the Console to generate a token manually. As a result, the deploy script could only be exercised with --dry-run, never against the live API. Event 9: ```text no qovery env vars ``` Event 116: ```text Failed: No organization found for this API token. ``` - **Deploying requires a provisioned cluster, which needs a connected cloud account**: Qovery's environment-create API accepts an optional cluster ID, but without one the environment cannot deploy. Provisioning a cluster requires connecting a real AWS/GCP/Azure/Scaleway account to the Qovery org, which is a legitimate product requirement (not a bug) but is beyond what a lightweight SDK/API-only example can achieve without infrastructure credentials. Event 111: ```text note: no QOVERY_CLUSTER_ID set; the environment has no cluster and cannot deploy. ``` #### Suggested Changes - **Add a working curl/API quickstart example directly in the API reference page**: The API reference's 'Getting Started' page (www.qovery.com/docs/api-reference/getting-started.md) 404s, forcing the agent to piece together the project/environment/application creation flow from the raw OpenAPI spec across many separate lookups. Add a concrete end-to-end example (create project -> environment -> application -> deploy) to the API reference intro so a new developer does not need to reverse-engineer the flow from the spec. Verify by requesting that exact URL and confirming it returns the walkthrough instead of a 404. Event 82: ```text # Page Not Found The requested page could not be found. ``` - **Clarify that a provisioned cluster is required before any application can deploy**: The CreateEnvironmentRequest schema marks 'cluster' as optional, but a deploy silently cannot proceed without one. Document this dependency (e.g., in the API authentication or quickstart doc) so developers know up front that a cluster from a connected cloud account is a prerequisite for the deploy step, not just an optional field. Check by looking for an explicit note near the environment-create or deploy API docs. Event 71: ```text "cluster": { "type": "string", "format": "uuid" }, ``` ### Kimi K3 [View public run](https://agents.withgauge.com/p/runs/ea6c822a-f24f-4d16-9961-e771e4246c48) · [Read transcript](https://www.ax-check.com/qovery.com/sessions/kimi.json) Gave tier prices from memory (Team ~$100/mo, Business ~$450/mo). Named plan tiers as assumptions, said cloud compute is billed separately, and said to verify. Did not fetch the pricing page. (seq 14, seq 36) #### End-to-end onboarding - **Onboarding needs a login**: The agent never obtained Qovery credentials of any kind. It checked the sandbox environment for API keys/config, hit the public API endpoint and got a 401 (auth required), then explicitly stopped because minting a token requires a browser-based signup/OAuth flow plus connecting a cloud account and provisioning a cluster (a ~30 min background wait). No authenticated API call to Qovery was ever made; deploy.sh was written but never executed. Event 4: ```text env | grep -i -E 'qovery|api_key|token' | sed 's/=.*/=/' ``` Event 9: ```text 401 ``` Event 36: ```text There is no Qovery API token in this environment, and tokens can only be minted from the Qovery web console after signup (a browser-based flow I can't complete — I have no email/OAuth identity). ``` #### Hallucinated URLs None identified in this transcript. #### Blockers - **No Qovery account/token available in sandbox**: The sandbox had no Qovery credentials, and acquiring one requires a human to sign up via the web console (browser/OAuth flow), which the agent cannot do on its own. This is a missing-credentials/session limitation, not a product defect — normal login is expected for any SaaS API. Event 4: ```text env | grep -i -E 'qovery|api_key|token' | sed 's/=.*/=/' ``` Event 36: ```text There is no Qovery API token in this environment, and tokens can only be minted from the Qovery web console after signup (a browser-based flow I can't complete — I have no email/OAuth identity). ``` - **First-use setup requires connecting a cloud account and a long-running cluster provision**: Even with a token, Qovery's workflow requires connecting the user's own AWS/GCP/Scaleway account and provisioning a Kubernetes cluster, described as a ~30-minute background operation. This conflicts with the session's instruction to avoid long-running waits, so the agent stopped rather than attempt it. This is product behavior (infrastructure bootstrap requirement) interacting with the test's no-long-wait constraint. Event 36: ```text Even with an account, first use requires **connecting your own cloud account** (AWS/GCP/Scaleway credentials, which I don't have) and **provisioning a Kubernetes cluster**, which Qovery itself describes as a ~30-minute background operation — a long-running wait you told me to avoid. ``` #### Suggested Changes - **Offer a token-only sandbox/demo cluster path for first-time API users**: Quickstart docs could surface a lightweight shared or trial cluster option so a new API user can test project/environment/application creation calls without first connecting personal cloud credentials and waiting ~30 minutes for cluster provisioning. Verify by having a fresh account attempt the README's deploy.sh flow end-to-end in under a few minutes. Event 36: ```text Even with an account, first use requires **connecting your own cloud account** (AWS/GCP/Scaleway credentials, which I don't have) and **provisioning a Kubernetes cluster**, which Qovery itself describes as a ~30-minute background operation — a long-running wait you told me to avoid. ``` ### Qwen 3.8 Max [View public run](https://agents.withgauge.com/p/runs/a4ca56de-2f9a-45f8-8089-96457a48cf7c) · [Read transcript](https://www.ax-check.com/qovery.com/sessions/qwen.json) Quoted plan prices from the fetched pricing page: Starter $299/mo billed yearly with users, clusters and minutes; $0.16/min overage; 14-day trial; separate cloud bill. (seq 21, seq 34) #### End-to-end onboarding - **Onboarding needs a login**: Agent found no Qovery credentials in the sandbox environment and never obtained any during the session. It confirmed the live API requires auth (401 on /user, /organization, /cluster) but had no self-service path to acquire a token, so it stopped and asked the user to supply one. No authenticated operation was ever attempted. Event 7: ```text no qovery CLI ---ENV CREDS--- AWS_CA_BUNDLE= PI_GATEWAY_API_KEY= ---TOKEN FILES--- no ~/.qovery ``` Event 26: ```text user -> 401 organization -> 401 cluster -> 401 ``` Event 34: ```text Qovery API token in env / `~/.qovery` | absent ``` #### Hallucinated URLs None identified in this transcript. #### Blockers - **No Qovery or cloud-provider credentials available**: The sandbox had zero Qovery tokens and zero cloud IAM credentials (AWS/GCP/Azure/Scaleway). Every real API endpoint returned 401, confirming the API is live but requires auth the agent had no way to self-provision. This is a missing-credentials limitation of the test environment, not a product defect — Qovery normally expects a human to sign up and generate a token. Event 7: ```text no qovery CLI ---ENV CREDS--- AWS_CA_BUNDLE= PI_GATEWAY_API_KEY= ---TOKEN FILES--- no ~/.qovery ``` Event 26: ```text user -> 401 organization -> 401 cluster -> 401 ``` - **Minimum viable workflow requires long-running cluster provisioning**: Even hypothetically with credentials, Qovery's docs state a managed Kubernetes cluster takes about 30 minutes to provision, which conflicts with the session's explicit instruction to avoid long-running commands. This is inherent product behavior (infrastructure provisioning takes real time), not an agent error, and it led the agent to stop proactively rather than attempt a workaround. Event 28: ```text Provision Managed Kubernetes on AWS, GCP, Azure, Scaleway. Ready in 30 min. BYOK supported. ``` Event 34: ```text The minimum unit of work is creating a managed cluster, which their own docs describe as **"Ready in 30 min."** That's a long-running provisioning operation — exactly what you told me not to wait on. ``` #### Suggested Changes - **Add a scoped read-only trial token option for sandboxed/agent evaluation**: The agent noted it could do safe, fast read-only API exploration (list clusters, fetch status, pull logs) if given a token, but had no self-service way to obtain even a limited-scope token during the session. Consider offering a lightweight, instantly-issued read-only API key (separate from full account signup) so automated or first-time evaluators can validate the API surface without waiting on cluster provisioning. Check this works by confirming a freshly generated read-only token can call GET /organization and /cluster successfully outside of a full paid signup flow. Event 34: ```text drive the API for **read-only** operations (list clusters, fetch status, pull logs) where a token alone is enough and nothing is mutated. Those are safe and fast. ``` ### Task given to each agent Help me build a simple example using Qovery. Tell me how pricing works, and briefly tell me whether this product will be easy for you to manage. Let me know if you get blocked. If this product has no developer workflow you can act on, say so plainly and stop. Stay light: use the hosted product through its SDK or API. Do not start local service stacks or wait for long-running commands; if the quickstart requires either, say so plainly and stop. No product credentials were supplied and no purchases were authorized. ## Score: B · 84/100 (provisional) Grades come from completed site checks. Coding sessions and skipped checks do not affect the score. ### Clarity - **Failed** — Homepage answers Markdown requests ```text Homepage returned text/html even when text/markdown was requested; no Markdown representation offered. ``` - **Pass** — llms.txt provides an actionable documentation index ```text llms.txt links docs, quickstart, API reference, MCP, skills and key pages with organized sections. ``` - **Pass** — llms.txt provides navigation guidance ```text llms.txt groups links under clear headings like Documentation, Interfaces, Guides and Quickstart. ``` - **Pass** — llms.txt mentions offered API, MCP, and skills ```text llms.txt describes the REST API, MCP Server and eight Agent Skills with links. ``` - **Pass** — A compact guide representation exists ```text AI Agent quickstart served as text/markdown with install command and workflow steps. ``` - **Pass** — A focused guide is directly retrievable ```text Quickstart page fetched directly as Markdown at /docs/getting-started/quickstart/ai-agent. ``` - **Pass** — Equivalent instructions fit a token budget ```text Markdown quickstart is 3731 tokens, well under the 8000-token budget. ``` - **Skipped** — Product-docs links survive format changes ```text Homepage Markdown unsupported, so link preservation across formats cannot be measured. ``` - **Pass** — The compact guide is independently actionable ```text AI Agent quickstart gives install command, prerequisites, prompt, and next steps. ``` - **Pass** — Install and next-step links resolve ```text Install script and docs links fetched successfully; skill install and MCP docs resolve. ``` ### Onboarding - **Pass** — Docs lead to a relevant quickstart ```text Quickstart index links AI-agent, CLI, Docker and BYOC paths; AI-agent page gives concrete install and prompt steps. ``` - **Pass** — Installation commands are extractable ```text Install commands extractable: skill installer curl, brew install qovery-cli, scoop, docker run, get.qovery.com script. ``` - **Pass** — Code examples are available without interaction ```text Code examples shown inline without interaction: curl install, claude mcp add, brew/qovery auth/deploy commands. ``` - **Pass** — Prerequisites and auth boundaries are explicit ```text Prerequisites listed (Qovery account, Git repo); auth via qovery auth or Q_CLI_ACCESS_TOKEN, MCP read-only by default. ``` ### Pricing - **Pass** — Pricing is readable without interaction ```text Pricing page renders all plan tiers and prices as static text without interaction. ``` - **Pass** — Prices are stated, not gated ```text Starter $299, Growth $899, Scale $2,999 per month stated publicly; Enterprise custom. ``` - **Pass** — Pricing units and limits are explicit ```text Units explicit: users, clusters, deployment minutes, overage $0.16/min, $4,788/cluster/year. ``` - **Pass** — Agents identify pricing and its assumptions ```text 2 of 3 sessions were judged on pricing; 0 fell short. Kimi K3: Gave tier prices from memory (Team ~$100/mo, Business ~$450/mo). Named plan tiers as assumptions, said cloud compute is billed separately, and said to verify. Did not fetch the pricing page. (seq 14, seq 36) Qwen 3.8 Max: Quoted plan prices from the fetched pricing page: Starter $299/mo billed yearly with users, clusters and minutes; $0.16/min overage; 14-day trial; separate cloud bill. (seq 21, seq 34) This behavioural item does not affect the fast grade. ``` ### Activation - **Pass** — An API reference or OpenAPI spec is reachable ```text API reference docs and a public OpenAPI spec at raw.githubusercontent.com/Qovery/qovery-openapi-spec are reachable. ``` - **Pass** — An MCP server is documented and well-formed ```text MCP server documented: remote HTTP endpoint, OAuth/token auth, read-only default, registry com.qovery. ``` - **Pass** — A CLI install path is documented ```text CLI install documented: brew install qovery-cli, curl installer, Scoop, AUR, Docker. ``` - **Pass** — SDK packages resolve on their registries ```text Official SDKs documented: @qovery/client on npm and qovery-client-go on pkg.go.dev. ``` - **Pass** — Agent skills are published ```text Eleven Qovery agent skills published on GitHub following the Agent Skills standard. ``` [Full report data](https://www.ax-check.com/qovery.com/report.json)