last comment
⌘K
system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/domains/troubleshooting
sam We need authoritative guidance for one files-based Preview deployment in an existing Vercel project. Required invariants: Every existing configured, branch, member, and custom-domain alias must retain its current deployment throughout creation. The new deployment must have only its immutable deployment URL and zero aliases. No Production deployment or project-setting change is authorized. CLI 62.1.0 documents --skip-domain as Production-only. Is there a supported CLI, REST API, or project control that prevents all automatic alias assignment for Preview? Please specify the exact supported param
Amy Egan As you already saw in the documentation, --skip-domain is used with the --prod option. Branch deployments get their own branch domain that is automatically updated to the latest deployment from that branch. Each deployment also gets a unique URL. The unique deployment URL stays with that deployment, and a new one is assigned to the next deployment. If you need a fixed domain then I'd recommend using the unique generated URL. If you can explain more about the bigger picture for your situation, I might have some other ideas about how to accomplish what you need.
system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/domains/troubleshooting
Rmjabor Thanks. I’ve already gone through the standard domain troubleshooting steps. This does not appear to be a DNS, ownership, SSL, or propagation issue. The inconsistency is internal to Vercel: vercel domains inspect reports the domains on cifrei-app; the project-domain API by project ID reports both domains attached and verified on cifrei-dre; adding them to cifrei-dre returns alias_conflict; removing them from cifrei-app says they are not assigned there. Vercel’s own diagnostic also indicated stale historical alias references on the production deployment target of cifrei-app. Could someone from
system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.
Chris Following up with more context. I've found several other reports on this board describing the exact same fingerprint (control plane shows a correctly aliased, verified, Ready deployment; edge returns X-Vercel-Error: NOT_FOUND regardless): Ready/Promoted production deployment returns NOT_FOUND on all hostnames Custom domain 404 NOT_FOUND despite valid config and healthy deployment - CLI evidence [\[Bug\] Custom domain returns 404 NOT_FOUND — edge routing entry missing](community.vercel.com/t/bug-custom-domain-returns-404-not-found-edge-routing-entry-missing/46169) That last thread has some real
Chris Update: worth flagging a detail about this project's setup that might be relevant. This project has two apex-level production domains attached: eopinion.org (main site) and eopl.ink (a short-link domain on the same project, redirected via hostname-based middleware logic). I've just confirmed eopl.ink is also returning the identical X-Vercel-Error: NOT_FOUND, so it's not that one domain is healthy and the other broken, they're both down together. One thing I noticed throughout: every vercel --prod deploy auto-aliased eopl.ink in its terminal output but never eopinion.org, consistently, across m
Craiguito This is usually tied to the exact author on the commit Vercel is deploying, not just the email on your GitHub profile. Check the commit that failed: git log -1 --format='%an <%ae>' Then compare that email to the email GitHub shows for that commit on github.com. If the commit uses an old email, a private noreply email that is not tied to your account, or a bot author, Vercel can treat it as an outside collaborator on Hobby. The fix is usually to set git author email locally, make a new commit, and push that: git config user.name "Your GitHub name" git config user.email "your_verified_github_ema
Ryu Hi Abhi, For Hobby projects connected to a private GitHub repo, Vercel needs to verify that the commit author is the Hobby team owner. So I’d check the actual commit author, not only the email on your GitHub/Vercel profile. Run this on the commit that failed: git log -1 --format="%an <%ae>" Then open that commit on GitHub and confirm GitHub associates it with your GitHub user. If GitHub shows it as unverified, unknown, a bot, or a different account, Vercel may treat it like an outside collaborator even if you are the only person using the repo. If the email is wrong, set it locally and push a
Tianen Pang check this one github.com/vercel/next.js/issues/89764#issuecomment-3928272828 for temp fix
ADALIGO The error comes from tooling mismatch not from you Luknuts56, just downgrade ESLint and you’re good 👍
Ryu Hi Luknuts56, This one looks like a tooling-version mismatch, not a problem with your loading.tsx file. Your package.json has: "eslint": "10.0.3", "eslint-config-next": "^16.1.7" and the stack trace is failing inside eslint-plugin-react while loading the react/display-name rule. There’s an open Next.js issue for this same ESLint 10 error: github.com/vercel/next.js/issues/89764 For now I’d pin ESLint back to v9 instead of using ESLint 10: pnpm add -D eslint@^9 eslint-config-next@latest pnpm lint If it still keeps ESLint 10 because of the lockfile, do a clean install: rm -rf node_modules pnpm-lo
Craiguito I’d isolate the database package before blaming Vercel or the whole template. From a clean folder, try the init with pinned tooling instead of all latest versions: corepack enable corepack prepare pnpm@9.15.4 --activate npx next-forge@latest init If it still creates the repo but fails at @repo/database, cd into the generated project and run: pnpm --filter @repo/database build That should give you the real TypeScript/ORM error instead of Turbo’s wrapper error. The log in the post only says the package build failed, not why. My guess is a version mismatch between the template’s database package
Ryu Hi Segal, The log you posted is still Turbo’s wrapper error, not the actual database package error. I’d isolate @repo/database first before treating the whole template as broken. From a clean terminal, try pinning the toolchain instead of using whatever “latest” resolves to: node -v corepack enable corepack prepare pnpm@9.15.4 --activate pnpm -v npx next-forge@latest init If the init still fails but leaves a partial repo behind, go into that repo and run the failing package directly: pnpm --filter @repo/database build or: cd packages/database pnpm build That should show the real TypeScript / O
