#builds

Jacob Paris This looks great, I like that you copied the shadcn theming shape so it feels more familiar. Your included themes do look more like recolors though, it would be cool to have more variety like tweakcn.com

Aniket Pawar Thanks Jacob, theme builder is underway and will be released soon.

Amy Egan so cute

Belty6979 5979 Really impressive how much you’ve packed into the calculator layer, especially keeping the calculations client-side while still maintaining a consistent UI across so many tools. I’ve been working on a simpler age-calculation tool as well, and one thing I’ve found interesting is how much the experience improves when the result shows the exact breakdown rather than just a single number. Projects like this make it clear that calculators can be useful standalone tools, not just small features inside a larger app. For anyone interested in seeing a more focused example of that approach: https://myagecalculate.com/

BestCodes Super excited to try Next.js 16.3 soon Added to my reading list!

Amy Egan Do you see an error message on the commits? That would have more details about what's going wrong. You can also try using the CLI to run `vercel build` and get more info if there is a configuration error preventing the build

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. https://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.

Amy Egan There are a lot of possible causes. I hope you were already able to solve it using the tips shared by the bot. If not, it would be helpful to see the site and code to get a better understanding of what's going wrong in this case. Are you able to share a minimal reproducible example or a publicly accessible URL for the site?

Ryu Hi Senseijayrome, I’d verify the Git link in two places before pushing anything. In Vercel, open the project → Settings → Git and confirm it shows the exact GitHub repo and production branch you expect, usually `main`. In GitHub, also check that the Vercel GitHub app has access to that same repo. For the first deployment, the usual path is: ``` git status git remote -v git branch git push origin main ``` If Vercel is connected correctly, a push to the production branch should create a production deployment. A push to any other branch should create a preview deployment instead. Before pushing, I’d also check: * Framework Preset: Next.js * Root Directory: only set if the web app is inside a subfolder * Build command / install command: leave defaults unless your app needs custom commands * Environment Variables: add any backend/database keys to the correct Vercel environment before deploying If this started in v0, note that v0 usually works on its own branch and then opens/merges a PR into `main`. After that merge, Vercel should deploy from the connected production branch. Since you mentioned Expo/React Native too, I’d keep that separate from the Vercel web deployment. Vercel should deploy the web/Next.js app; Expo native builds are normally handled through the Expo workflow, not Vercel. If a push does not create a deployment, the most useful screenshot would be Project Settings → Git showing the connected repo and branch, with private details hidden.

Westborg Found it - solved. Posting in case anyone else hits this. Root cause: `vercel.json` had an hourly cron (`0 `). Hobby accounts only support daily crons. The dashboard/GitHub-triggered deploy pipeline was silently dropping every deployment because of this - no error anywhere in the Deployments list (even with all status filters on) or the Activity log, and even a manually triggered Deploy Hook just returned `{"job":{"state":"PENDING"}}` and produced nothing. What actually surfaced the real error was deploying via the Vercel CLI directly: ```` npx vercel --prod ``` That returned this explicit error immediately: ``` { "status": "error", "reason": "deploy_failed", "message": "Hobby accounts are limited to daily cron jobs. This cron expression (0 * * * *) would run more than once per day. Upgrade to the Pro plan to unlock all Cron Jobs features on Vercel." } ``` Fix: changed the cron schedule to run once a day instead of hourly, pushed, and deployments immediately started working again via git push as normal. Would be great if this validation error could also surface in the dashboard / on git-triggered deployments and Deploy Hook responses, instead of only appearing via the CLI - it cost a lot of time to track down since every other signal (Git connection, GitHub App permissions, deploy hook response) looked healthy. ````

CoffeePuma55644 As an additional test, I also removed Bun as the runtime for the build while keeping Bun enabled for the Serverless Functions. The build completed successfully, but every Server Function immediately returned an **Internal Server Error** at runtime. The only configuration that currently works reliably for me is to use **Bun only as the package manager**, while letting Next.js run with the default runtime for both the build and the Serverless Functions. Hopefully this additional information helps narrow down where the issue might be.

Louis Pretty much the same problem here. Since updating to 16.3, \`bun run build\` (1.3.14) fails on my Railway deployment, although it works locally. Reverting back to 16.2.12 fixed the issue

Ryu Hi CoffeePuma55644, Since you reproduced it with a fresh Next.js 16.3 app, I’d treat this as a compatibility issue between Next.js 16.3 and the Bun runtime path, not just your application code. There are two separate things to separate here: ``` Bun as package manager bun install Bun as the runtime used to execute the Next build bun run --bun next build ``` For the Function runtime, Vercel’s Bun config currently uses: ``` { "bunVersion": "1.x" } ``` and Vercel manages the minor/patch version, so I wouldn’t assume you can force Functions specifically onto `1.3.14` from `vercel.json`. For the build/install side, Vercel has a KB article for pinning Bun in the Install Command, so you could try this as a narrow test: ``` bunx bun@1.3.14 install ``` https://vercel.com/kb/guide/how-to-pin-a-specific-bun-version-for-vercel-builds If that still fails during “Collecting page data,” then the issue probably is not just the install-time Bun version. In that case, your current workaround is the one I’d use for production: keep Bun only as the package manager if you want, remove the Bun runtime config, use the normal `next build` path, or temporarily stay on Next.js `16.2.12`. If you can share the minimal repro’s `package.json` scripts and `vercel.json`, that should make it much easier for Vercel/Bun maintainers to confirm whether the failure is in the build runtime, Functions runtime, or the Next.js 16.3 output.

Ryu Hi Zangyj1971, I don’t think another community member can reliably confirm whether CLI issue #17069 is still present in `58.0.0`, but you can separate the documented workflow from the suspected bug pretty cleanly. The documented CLI behavior is that a normal CLI deploy without `--prod` should create a Preview deployment, while `--prod` creates Production. So for a fresh linked project, the safest thing to test is: ``` vercel deploy --target=preview --logs vercel inspect <deployment-url> ``` Then check the inspected deployment’s environment/target before using it in any release flow. For Git, Vercel treats the configured production branch as Production and other branches as Preview by default. So connecting Git and making sure the first pushed branch is not the configured production branch should be the safer supported workflow, but I’d still verify the first deployment in the dashboard or with `vercel inspect` before treating that as a compliance guarantee. The relevant docs are here: https://vercel.com/docs/deployments/environments Given your policy says “no Production-target deployment at any time,” I would avoid relying on placeholder deployments or `--skip-domain`; those can avoid assigning traffic/domains, but they are not the same as proving the deployment target was Preview.

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. https://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.

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. https://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.

Ryu Hi Solomon, The `Functions` tab only showing `/api/auth/[...nextauth]` is not necessarily a problem by itself. Static App Router pages will not always show up there as functions. The more important signal is the exact 404 type and which URL is returning it. I’d separate three cases: ``` 1. Unique deployment URL returns 404 2. Project/production alias returns 404 3. Only specific app paths like /todo return 404 ``` Can you test the unique deployment URL from the deployment details page, not just the project alias? ``` curl -I https://<deployment-id-or-unique-url>.vercel.app/ curl -I https://<deployment-id-or-unique-url>.vercel.app/todo curl -I https://study-hub-phi-sand.vercel.app/ curl -I https://study-hub-phi-sand.vercel.app/todo vercel inspect <deployment-url> ``` If the unique deployment URL works but `study-hub-phi-sand.vercel.app` returns `DEPLOYMENT_NOT_FOUND`, that points to an alias/routing association issue. If the unique deployment URL also returns Vercel’s platform `DEPLOYMENT_NOT_FOUND`, then that is much stronger evidence that the deployment is not being served at the edge even though the dashboard says Ready. The most useful escalation details would be: ``` deployment URL tested: production alias tested: deployment ID: exact UTC timestamp: x-vercel-id from the 404 page: vercel inspect status/target/aliases: ``` I’d avoid redeploying repeatedly for now unless you need to restore service, because the current broken deployment state may be what Vercel needs to inspect.

Josh To add, I have a hobby account on Vercel and a Pro account. I was trying to add the personal GitHub to the hobby account and keep the work GitHub on the pro account. Maybe I really only have one account on Vercel (I saw that only 1 GitHub account may be used per Vercel account – the UI is confusing here because then why does it say *Add* Account)?

Amy Egan Yes, you can connect one GitHub account to a single Vercel account. That is the expected behavior. https://vercel.com/kb/guide/connecting-teams-with-personal-git-accounts

ADTC FWIW, you can set up GitHub Actions to indirectly deploy your projects into Vercel without connecting your GitHub account. See https://gist.github.com/ADTC/63ce24ca5a6c306f05d75ad2d6975e93

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. https://vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryu Hi Hero, I’d first separate “Safari is slow to get the document” from “Safari gets the document quickly but renders a blank page for a while.” A quick way to check is to run this in Safari’s console after a slow load, then compare it with Chrome on the same iPhone: ``` const n = performance.getEntriesByType("navigation")[0]; console.table({ dns: Math.round(n.domainLookupEnd - n.domainLookupStart), connect: Math.round(n.connectEnd - n.connectStart), tls: Math.round(n.requestStart - n.secureConnectionStart), ttfb: Math.round(n.responseStart - n.requestStart), download: Math.round(n.responseEnd - n.responseStart), dom: Math.round(n.domContentLoadedEventEnd - n.responseEnd), total: Math.round(n.loadEventEnd - n.startTime), }); ``` If `dns`, `connect`, `tls`, or `ttfb` is much higher only in Safari, I’d test Safari with iCloud Private Relay/content blockers disabled, and compare Wi-Fi vs mobile data. I’d also compare the custom domain against the `*.vercel.app` URL. If the Vercel URL is fast but the custom domain is slow, then I’d look at DNS, SSL, or anything proxying the domain. If the network numbers look normal but the screen stays blank, then I’d focus on client rendering: large JS, blocking third-party scripts, fonts, CSS, hydration, or an app shell that does not render meaningful HTML before client code runs. One useful isolation test is adding a very small static page, for example `/plain`, that only returns simple text and no heavy components. If Safari loads `/plain` instantly but the homepage is slow, the issue is probably in the page code/assets. If `/plain` is also slow, the issue is more likely network/domain/browser-path related. The most useful detail to share next would be the timing table from Safari and Chrome for the exact same URL.

Ryu Hi Senseijayrome, v0 creates its own working branch off `main` when a chat is connected to GitHub, so if it is stuck at “Create Branch” I’d first separate repo permissions from the v0/GitHub connection state. A few things I’d check: 1. In GitHub, confirm the Vercel/v0 GitHub app has access to `AtlasJamaica/atlas-transportation-solutions-jamaica`, not just your GitHub account generally. 2. Check whether the repo has branch protection or repository rulesets that block creating or pushing branches matching `v0/*`. 3. Try creating a test branch manually from `main`: ``` git fetch origin git checkout -b v0/manual-test origin/main git push origin v0/manual-test ``` If that manual push fails, the blocker is probably GitHub repo permissions/rules. If it succeeds but v0 still hangs on “Create Branch”, then the issue is more likely the v0 Git connection state for that chat/project. I’d also avoid deleting the original v0 chat while testing if that’s the only place the Atlas code still exists. The most useful non-sensitive detail to add would be the exact Git panel error from v0 and whether the manual `v0/manual-test` branch push succeeds.