Skills

Skill 14 of 33

Convex Domains

Point a domain you already own at your Convex app (DNS records, custom-domain attach, auth-origin rebind).

2 minutes · 331 words · 3 sections

Install

$ npx skills add convex/agent-skills --skill convex-domains

$ npx skills add convex/agent-skills

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

Set up a custom domain with your own provider

Walk the user’s own registrar through pointing their domain at the Convex app: identify the target (hosting or deployment URL), create the DNS records, attach the custom domain, and rebind the auth origin if the app uses auth.

Workflow

Identify the target: the published site host (for *.convex.app static hosting) or the deployment’s HTTP actions URL.
Detect an ALREADY-AUTHENTICATED DNS CLI for the user’s provider and OFFER to create the records automatically: Cloudflare → flarectl dns create (note: wrangler itself doesn’t manage DNS records) or the CF API via their token env; Route53 → aws route53 change-resource-record-sets; Google Cloud DNS → gcloud dns record-sets create; DigitalOcean → doctl compute domain records create; Vercel DNS → vercel dns add. Check auth read-only first (flarectl user info / aws sts get-caller-identity / doctl account get); show the exact commands and get a yes before running.
If no authed CLI (or the user declines), tell the user exactly which records to create at THEIR registrar: the CNAME (or A/ALIAS at the apex) plus the TXT verification record — with concrete host/value strings, not placeholders.
Attach the domain as a Convex custom domain (dashboard or CLI) and wait for verification; note DNS propagation can take minutes to hours. Verify records landed with dig +short.
If the app uses auth (passkeys/OAuth), rebind the auth origin (SITE_URL / RP_ID / ORIGIN env vars) to the new domain and re-deploy/re-publish.
Verify: the domain serves the app over HTTPS, including the apex → www redirect if configured.

Rules

Never ask for or handle registrar credentials. A CLI already authenticated on the user’s machine is fine — the credential stays in the tool; never install a CLI or run its login/auth flow for this, and never echo tokens.
DNS changes on a live domain are user-visible: show the exact commands and confirm before running them; verify afterwards with dig.
Always include the TXT verification record, not just the CNAME.
Rebinding the domain changes the auth origin — re-publish after, or sign-in breaks.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/convex/agent-skills, branch main, last pushed 29 October 2026.

Licence

Apache-2.0 — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

33 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. One layout observed: skills/*/SKILL.md.

Issue colours

Resolved from a curated brand profile — hue 80°, chroma 0.160. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Shifted “3 headings” from h1 to h2 so the skill title is the only h1.

Spec compliance

Every skill satisfies the Agent Skills specification’s frontmatter rules.

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /convex/agent-skills.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Set up a custom domain with your own provider

Identify the target: the published site host (for *.convex.app static hosting) or the deployment’s HTTP actions URL.

Detect an ALREADY-AUTHENTICATED DNS CLI for the user’s provider and OFFER to create the records automatically: Cloudflare → flarectl dns create (note: wrangler itself doesn’t manage DNS records) or the CF API via their token env; Route53 → aws route53 change-resource-record-sets; Google Cloud DNS → gcloud dns record-sets create; DigitalOcean → doctl compute domain records create; Vercel DNS → vercel dns add. Check auth read-only first (flarectl user info / aws sts get-caller-identity / doctl account get); show the exact commands and get a yes before running.

If no authed CLI (or the user declines), tell the user exactly which records to create at THEIR registrar: the CNAME (or A/ALIAS at the apex) plus the TXT verification record — with concrete host/value strings, not placeholders.

Attach the domain as a Convex custom domain (dashboard or CLI) and wait for verification; note DNS propagation can take minutes to hours. Verify records landed with dig +short.

If the app uses auth (passkeys/OAuth), rebind the auth origin (SITE_URL / RP_ID / ORIGIN env vars) to the new domain and re-deploy/re-publish.

Verify: the domain serves the app over HTTPS, including the apex → www redirect if configured.

Never ask for or handle registrar credentials. A CLI already authenticated on the user’s machine is fine — the credential stays in the tool; never install a CLI or run its login/auth flow for this, and never echo tokens.

DNS changes on a live domain are user-visible: show the exact commands and confirm before running them; verify afterwards with dig.

Always include the TXT verification record, not just the CNAME.

Rebinding the domain changes the auth origin — re-publish after, or sign-in breaks.