feat: support wildcard domains on Vercel - #8
Open
charliedevelops wants to merge 4 commits into
Open
Conversation
|
@charliedevelops is attempting to deploy a commit to the OpenCore Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Pull request overview
This PR enables wildcard hostname support (*.example.com) for the Vercel provider by advertising the capability, adding a regression test to ensure the wildcard is sent intact to Vercel, and updating the provider documentation/capability matrix to reflect the operational requirements for wildcard certificates.
Changes:
- Enable
wildcardDomains: truein the Vercel adapter capabilities (with an operator-focused caveat comment). - Add a provider test asserting a wildcard hostname is POSTed as
*.customer.com(not folded to the apex). - Update Vercel provider docs and the provider capability matrix to reflect wildcard support and requirements.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/sdk/test/providers/vercel.test.ts | Adds a test to ensure wildcard hostnames are attached intact when calling the Vercel adapter. |
| packages/sdk/src/providers/vercel/index.ts | Flips Vercel capability flag to support wildcard domains and documents operational caveats. |
| apps/fumadocs/content/docs/providers/vercel.mdx | Updates Vercel provider docs to describe wildcard support and certificate/verification requirements. |
| apps/fumadocs/content/docs/providers/index.mdx | Updates the capability matrix and provider comparison text to include Vercel wildcard support. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+96
to
+99
| if (url.pathname === "/v10/projects/prj_123/domains" && method === "POST") | ||
| return json(wildcard); | ||
| if (url.pathname === "/v6/domains/*.customer.com/config") return json(configuration); | ||
| return json({ error: { message: `Unhandled ${method} ${url.pathname}` } }, 500); |
Greptile SummaryThis change enables Vercel wildcard-domain support, adds full wildcard lifecycle coverage, and updates the provider documentation to describe the supported DNS behavior. Confidence Score: 5/5No blocking failure remains. Wildcard domain operations completed successfully through the Vercel adapter, with normalized hostnames and expected provider request paths.
 T-Rex LogsWhat T-Rex did
Reviews (3): Last reviewed commit: "docs: name every adapter that exposes wi..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
charliedevelops
marked this pull request as draft
August 15, 2026 22:55
The adapter declared `wildcardDomains: false`, so `createDomainClient` rejected `*.example.com` in `normalizeHostname` and `provisionWildcard()` refused with `UNSUPPORTED_OPERATION` — Vercel never saw the request. Vercel accepts a wildcard project domain: `POST /v10/projects/:id/domains` takes `*.example.com` as its `name`, and `get`, `verify`, `remove` and the config lookup all address it the same way. Verified against the live API: the hostname round-trips intact and removal is clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
charliedevelops
force-pushed
the
vercel-wildcard-domains
branch
from
August 15, 2026 23:01
17b1522 to
abfa79f
Compare
The capability advertises wildcard support for every operation, but only `add` was exercised. A regression in wildcard URL construction or response normalization for `get`, `refresh`, `verify`, `list` or `remove` would have passed the suite. Covers all six, asserting the normalized hostname stays `*.customer.com` and the request paths carry the wildcard literally — `encodeURIComponent` leaves `*` alone, so `/v9/projects/:id/domains/*.customer.com/verify` is the real path and an encoding change would silently break it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
charliedevelops
changed the title
The first draft claimed the apex must be verified on the account and that a DNS-01 ownership record has to stay in place for renewal. Neither held up against the live API: attaching a wildcard for a domain nobody owns returns `verified: true` immediately, and a wildcard serving traffic today does so from a third-party DNS provider with no `_acme-challenge` record anywhere in the zone. Replaces both with what was observed. Adds the `misconfigured` semantics, which are easy to misread: the field is evaluated against the project named in the request, so a wildcard attached to a different project reports `misconfigured: true` with an empty `acceptedChallenges` even though its DNS is correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
charliedevelops
marked this pull request as ready for review
August 16, 2026 04:50
The managed-subdomains guide said Render was the only one. bunny.net has declared the capability since 0.2.0, and Vercel does as of this branch, so the page a reader lands on while building exactly this was pointing them away from two of the three adapters that support it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Vercel adapter declares
wildcardDomains: false.createDomainClientpasses that flag tonormalizeHostnameasallowWildcard, soadd("*.example.com")throwsINVALID_HOSTNAME, andcreateSubdomainClient'sprovisionWildcard()throwsUNSUPPORTED_OPERATION. Both fail before a request reaches Vercel.Vercel supports wildcard project domains.
POST /v10/projects/:id/domainsaccepts*.example.comasname, andget,verify,list,removeand the domain-configuration lookup address it identically. No adapter code below the capability flag treats a wildcard differently.Why no adapter code
The other two adapters that declare
wildcardDomains: trueboth branch on wildcards, so it is worth saying why this one does not. Render's API returns no DNS records, so its adapter synthesizes them from known conventions and a wildcard needs an extra_acme-challengeCNAME it has to author itself; bunny.net does the same for DNS validation.The Vercel adapter reads its records instead —
recommendedIPv4andrecommendedCNAMEfrom/v6/domains/:d/config, and the challenges from the project-domain response — so whatever a wildcard requires arrives through fields it already maps. The generic wildcard handling incore/hostname.tsandcore/subdomains.tswas already there; the capability flag was the only gate.One gap this leaves: the adapter does not read
acceptedChallenges. If Vercel returns a wildcard certificate challenge only in that field rather than inverification[], it would not reach the caller. Every wildcard checked here was either already serving or unowned, so that state was not observable from outside.Changes
wildcardDomains: trueon the Vercel adapter.add,get,refresh,verify,listandremove, asserting normalized hostnames and request paths. Paths keep a literal*, sinceencodeURIComponentdoes not escape it.provisionWildcard()is left to its existing coverage intest/core/subdomains.test.ts, which already exercises both capability states against a provider.Verified against the live API
Rather than inferred from documentation:
hostnameround-trips as*.example.comrather than folding to its apex, andremoveis clean.configuredByreportsAorCNAMEdepending on which record shape is used. Both work, and Vercel's own nameservers are not required — the wildcards checked are served from third-party DNS.misconfiguredis evaluated against the project named in the request. A wildcard whose DNS is correct but which is attached to a different project reportsmisconfigured: truewith an emptyacceptedChallenges. That is documented, since it is easy to read as a DNS fault.An earlier revision of this PR claimed the apex must be verified on the account and that a DNS-01 ownership record must persist for renewal. Neither survived checking, and both were removed in 7e154dd.
Testing
packages/sdk:bun test(68 pass),check-types,lint,buildapps/fumadocs:check-types,lint,buildtest,typecheck,lint,build