Qovery Sign-up Skill

Qovery Sign-up Skill

Gets a brand-new user fully onboarded to the point of having an account and an organization: verify (or install) the Qovery CLI → sign in with qovery auth --headless (first login is the sign-up) → create an organization → set the CLI context → hand off to qovery-onboard for clusters and environments.

The whole flow leans on the Qovery CLI's own credential store — after qovery auth, every call authenticates internally, so no raw tokens ever flow through the shell or this conversation.

Usage Tracking

RUN THIS ONCE PHASE 3 HAS CREATED THE ORGANIZATION, passing that organization's id. Unlike every other skill in this repo, a brand-new sign-up has zero organizations until then — /organization returns an empty results array, so running it any earlier is a silent no-op and the event never fires.

# Replace NEW_ORG_ID with the organization id Phase 3 created — quoted, because bash
# reads a bare <placeholder> as a redirection and refuses the whole line.
bash '__QOVERY_SKILL_DIR__/scripts/track-skill-usage.sh' qovery-signup "NEW_ORG_ID"

API rule: send this exact User-Agent header on every curl call to api.qovery.com, spelled out in full each time — a shell variable set in one command is gone by the next one:

-H "User-Agent: QoverySkill/qovery-signup (version:__QOVERY_SKILLS_VERSION__; https://github.com/Qovery/qovery-skills)"

CRITICAL RULES

Authentication is the CLI's job — not yours. Never ask for, print, store, or paste raw tokens. The user signs in once with qovery auth --headless; after that, qovery api … and every qovery command use the locally stored credentials. See reference/auth.md.

qovery auth --headless is interactive and needs the user's browser. It prints a URL the user must open and complete (GitHub / GitLab / Google / email). You cannot do the browser step for them. In Claude Code, have the user run ! qovery auth --headless so the URL appears in-session; then wait for them to confirm they finished.

First login = sign-up. A brand-new user does not "register" separately — the account is created automatically on the first successful OAuth login. There is no API to create an account.

Do NOT ask the user to choose a plan, and never expose internal plan names. Always create the organization on BUSINESS_2025 by default (the individual tier isn't customer-selectable and Enterprise pricing is custom). Confirm only the org name before creating (org creation is a real, billable-tier resource). Deviate from BUSINESS_2025 only if the user explicitly names a plan themselves.

There is no qovery organization CLI command. Manage organizations through qovery api organization … (which uses the CLI's auth) or the REST API — not a CLI noun.

Set expectations about billing. A new organization has no credit card, so managed clusters and deployments are blocked (billing_deployment_restriction: NO_CREDIT_CARD) until one is added. A local demo cluster (qovery demo up) works with no card.

Sign-up tracking is tagged, consented, and best-effort. Phase 4 records the sign-up in Qovery's pipeline and the HubSpot lead funnel, always tagged signup_source: "CLI" / "AI-Agent" so it's distinguishable from web sign-ups. Only send data the user gave in the interview — never invent PII. The Cargo/HubSpot token comes from QOVERY_CARGO_INGEST_TOKEN (or backend forwarding) and is never committed or printed. Tracking must never block or fail the sign-up.

When to Use This Skill