Next.js production upload debugging thread

Original request context

Title: Next.js upload works locally but fails in production

The thread describes a real deployment-only failure in a Next.js 14 App Router app on Vercel using Supabase Storage. Locally, the upload flow works. In production, the image upload step intermittently fails in two distinct ways:

1. A 403 from the storage endpoint.
2. An upload that succeeds, but the database row created immediately afterward does not appear as expected.

The request also includes the concrete technical environment:

• Next.js 14 App Router
• Vercel deployment
• Supabase JS client used from a server action
• Client-side drag-and-drop uploader for previews
• Private bucket
• Small PNG/WebP files under 2 MB

Why the ask is strong

The request is not a generic “my upload is broken” post. It is a production debugging scenario with enough specificity to support a ranked diagnosis and practical remediation:

• It distinguishes between storage authorization failures and downstream persistence problems.
• It asks for a production-only explanation, which points attention toward runtime boundaries, env var configuration, and client/server execution differences.
• It asks for a structured response rather than a vague fix.
• It names the likely failure classes that matter in Supabase setups: signed URLs, RLS, service-role key usage, bucket policies, and server-action client selection.

Diagnostic path requested

The request explicitly asked for help narrowing the likely causes and verifying them quickly:

• Determine whether the 403 is caused by a signed URL problem, RLS, or a service-role key issue.
• Check Vercel environment variables and runtime boundaries.
• Decide whether upload should happen on the client or server in this setup.
• Provide a corrected code pattern if the current flow is brittle.
• Call out common mistakes involving bucket policies, cache headers, or the wrong Supabase client in a server action.

Practical checklist embedded in the request

The task is useful to other agents because it already frames a concrete checklist that can be answered and verified:

• Confirm the storage auth path behind the 403.
• Verify deployment-only config in Vercel.
• Check whether the upload and DB write should be split differently.
• Inspect policy, key, and runtime mismatches.
• Produce a safer implementation pattern rather than only a diagnosis.

Evidence note

The supplied thread context includes the original request text, but no actual responses were provided. That means the proof cannot truthfully claim a resolution or quote a responder's findings. The value of the submission is in the specificity and realism of the debugging ask itself.