#nextjs

Ryu Hi Tn0127, You probably do not need to change the production branch for this. If main is your real production branch, keep it that way. With a connected GitHub repo, a push to any other branch, like dev, should create a Preview Deployment instead of replacing production. So the usual flow would be: git checkout dev git push origin dev Then in Vercel, open the project → Deployments and filter by the dev branch. That deployment will have its own preview URL. If you want dev to have a stable staging URL, you have two options: Use the branch preview URL Vercel gives you for that branch. Add a cust

VX360 Hi @Tn0127, Actually, you don't need to change Git commands or push a new branch to do this. Vercel lets you control the project's production branch directly from the dashboard, which is the easiest and safest way: Open your project in the Vercel Dashboard. Go to the Settings tab. Select Git from the sidebar. You'll find a section called Production Branch. There, you can select the branch you want to use for deployment (Production) instead of main or any other branch, and change it to dev. Once you save this setting, Vercel will automatically consider any update pushed to the dev branch as an

Ryu Hi Anurag, I’d check whether getHoroscope() is being cached at request time rather than during prerender/static shell generation. The local vs Vercel difference can make this confusing: locally you usually have one long-running server process, so an in-memory use cache entry is easy to hit. On Vercel, if that dynamic route is evaluated at runtime, requests can land on different function instances/regions, so the default in-memory use cache entry may not be reused the same way. That would also explain why getMenu() works while getHoroscope(day, sign) does not: the menu may be part of a more sta

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/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.r

Ryu Hi Kishor, For IIS, I’d separate the problem into two parts: Turborepo build orchestration and how each Next.js app is served. Turborepo itself is not something you “deploy” to IIS as one running app. Usually you build each app separately, and the shared packages from packages/ are bundled/compiled into whichever app depends on them. From the monorepo root, the basic shape is usually: npm install npx turbo run build --filter=app-1 npx turbo run build --filter=app-2 npx turbo run build --filter=app-3 Then for each app you need to decide whether it is static or server-rendered. If an app is full

Ryu Hi Trylotsy, I’d separate this into a few different “old version” cases, because they have different causes. First, ask one affected user to open DevTools → Network and hard reload, then check the main document request for / or the affected route: Status: Cache-Control: x-vercel-cache: x-vercel-id: If the HTML document itself is old, I’d check for something in front of Vercel, like Cloudflare, a corporate proxy, browser cache, or a service worker/PWA. A service worker is a common cause when only some users keep seeing an older frontend after a successful deployment. If the HTML is new but the

Trylotsy Thanks for the response. The challenge is that this is affecting a consumer-facing application with a large mobile user base, so it isn't practical to walk individual users through DevTools checks, cache clearing, service worker inspection, or other device-specific troubleshooting steps. What we're seeing is inconsistent behavior across devices: Some users see the latest version on desktop but not mobile. Some see the latest version on mobile but not desktop. Some see the latest version on both. Some continue to see the old version on both. Because the issue appears random across users and dev

Ryu Hi Trylotsy, I don’t think there is a single Vercel-side purge that guarantees every already-open browser/device moves to the newest frontend bundle. For a normal Next.js deployment, the production alias should point at one deployment, and /_next/static/... assets are content-hashed, so old JS chunks usually only continue loading if old HTML or a client-side cache is still serving the old app shell. For the “random across users/devices” pattern, I’d focus on these deployment-level checks: Check whether you have a service worker/PWA layer, such as next-pwa, Workbox, a custom sw.js, or a previou

Ryu Hi Adam, I’d separate “the environment variable exists” from “the request is actually sending the right auth to the right place.” If this is using Vercel AI Gateway, the request should be server-side and should send the Gateway key as a bearer token to the Gateway endpoint, not expose it in the browser: const response = await fetch("ai-gateway.vercel.sh/v1/chat/completions", { method: "POST", headers: { Authorization: Bearer ${process.env.AI_GATEWAY_API_KEY}, "Content-Type": "application/json", }, body: JSON.stringify({ model: "openai/gpt-4.1-mini", messages: [{ role: "user", content: "test" }

Ryu Hi James, For an /api/og route handler, I'd first check the response headers rather than assuming it is cached automatically. In the App Router, route handlers are not cached by default unless you opt into caching or return cache headers. A quick test would be: curl -I "your-domain.com/api/og?type=page&id=example" curl -I "your-domain.com/api/og?type=page&id=example" Look at cache-control and x-vercel-cache. If you see MISS/no useful cache headers each time, the image is probably being regenerated on requests. For a generated OG image that can be reused, you can try adding cache headers to the

Ryu Hi Gabriel, I think keeping @vercel/related-projects server-side is probably the safer default. The package reads VERCEL_RELATED_PROJECTS, and exposing that automatically to the browser would turn deployment/project mapping metadata into public client-side data. For your use case, I'd put a very small server wrapper in front of it instead of trying to call the package directly from the browser. For example, in a Next.js Route Handler: import { NextResponse } from "next/server" import { withRelatedProject } from "@vercel/related-projects" export async function GET() { const apiHost = withRelate