Vercel domains and env vars: the Varel launch checklist
Recent Varel updates focus on the unglamorous launch path: domain availability, pricing checks, env synchronization, and production handoffs.
Varel Team / Product and engineering
Most launch checklists make the exciting parts visible: the landing page, the pricing card, the checkout button. The risk usually lives in quieter places: a stale preview variable, an unverified domain, an old callback URL, or a webhook pointed at the wrong environment.
Recent Varel work has focused on that layer. The core CLI now has more Vercel domain management support, including availability checks, pricing preparation, contact-schema guidance, and nameserver handling. It also improved Vercel env-var management so existing variables can be updated instead of blindly duplicated.
Why domains are not a final step
A domain is not just a nicer URL. Once the production domain changes, the rest of the SaaS surface has to follow it. Auth redirect URLs, webhook endpoints, email sender domains, Sanity preview origins, analytics allowed hosts, checkout success URLs, customer portal URLs, and sitemap canonicals can all depend on the final host.
That is why Varel treats domain work as an integration task, not a registrar task. The right question is not only whether the domain is available. It is what must be updated after the domain is attached and verified.
Dev, preview, and production are different products
A working local `.env.local` is not proof that production works. Vercel preview might use sandbox Clerk and Polar values while production needs live keys, live webhooks, production product IDs, and the final app URL. A launch checklist has to keep those targets separate.
Varel's setup model makes that explicit. Local-first guidance is allowed to stay development-only. Launch-ready guidance includes development, preview, and production, with provider-specific reminders for each environment.
The launch checklist Varel cares about
- Domain availability and price checked before a purchase decision.
- Explicit approval before buying or attaching a domain.
- Vercel project env values synchronized by target, not copied by hope.
- Clerk, Polar, Sanity, Resend, PostHog, and sitemap settings reviewed after the final URL exists.
- Production checks run after the setup changes, not before.
Why this matters for agentic development
An agent can easily update a `.env.example` file and miss the live Vercel value. It can update a pricing page and miss the Polar product ID. It can add Sanity metadata and forget the sitemap. Those are not coding failures exactly; they are cross-system state failures.
Varel's answer is to keep provider ownership explicit. Core gives the app a safe baseline. The CLI handles initialization and local setup paths. Hyperdrive tells the agent which provider state must be checked next. Together, they make the boring launch work harder to skip.
The practical standard
A SaaS app is not launched because the repo builds. It is launched when the production domain, production env, provider dashboards, webhooks, billing products, auth redirects, content routes, and verification checks agree with each other. That is the standard Varel is moving toward.