Replit Export to Vercel 2026: Fix Build Failures

Replit Export to Vercel: What Actually Changes

A Replit export to Vercel is not just a hosting switch. You are moving from a workspace that can run almost anything with hidden assumptions to a deployment platform that builds from Git, detects a framework, runs a build command, and serves the generated output. That is a stricter contract.

We have seen this in 40+ Replit apps where the code ran inside Replit but failed immediately on Vercel. The app depended on Replit Secrets, Replit DB, a shell command in .replit, a custom port, or a file path that only existed in the Replit workspace. Vercel does not read those assumptions unless you translate them into standard project files.

The Replit parts Vercel does not automatically understand

Replit often stores runtime behavior outside the normal package scripts. A Replit Agent app might have a working Run button even when npm run build is missing, incorrect, or never tested. Vercel does not click Run. It installs dependencies, runs the configured build command, and deploys the output.

• .replit run commands need to become package.json scripts.
• Replit Secrets need to become Vercel Environment Variables.
• Replit DB needs to be replaced with Postgres, Supabase, Neon, Upstash, or another external service.
• Local file storage needs to move to object storage if users upload files.
• Hardcoded localhost URLs need production-safe environment variables.

Use this migration map before touching Vercel

The safest approach is to treat the move as a production hardening pass. If the app was generated quickly by Replit Agent, assume the first build failure is not the real problem. It is usually the first visible symptom of several hidden environment and configuration issues.

Get Your Replit Code Out Without Losing the App

The best Replit migrate to Vercel workflow is GitHub first, Vercel second. You can download a zip for a quick inspection, but Git gives you rollback, branch history, and a clean path into Vercel. If your current pain is “nothing gets pushed to GitHub,” fix the Git state before importing the project into Vercel.

Start by confirming which files are actually part of your app. Replit projects generated by AI often contain abandoned folders, duplicate frontend directories, or a working app nested one level deeper than expected. We have opened Replit exports where Vercel was building the empty parent folder while the real Next.js app lived in /client or /frontend.

Export options that work in practice

1. Connect Replit to GitHub from the version control panel and push the current workspace.
2. Download a zip if GitHub sync fails, then initialize a local Git repository manually.
3. Use the Replit Shell to inspect files with ls, find, and cat package.json.
4. Push from local if Replit’s Git integration is stuck or disconnected.

If GitHub sync is broken, download the project, unzip it locally, then run the following commands from the folder that contains the real package.json:

git init
git add .
git commit -m "Export Replit app for Vercel"
git branch -M main
git remote add origin https://github.com/YOUR-USER/YOUR-REPO.git
git push -u origin main

Clean the repository before importing to Vercel

Do not push secrets, generated caches, or Replit-only clutter. Check for .env, node_modules, database dumps, and large upload folders. Vercel will install dependencies itself, and committed secrets can create a security incident before your migration is finished.

• Add node_modules, .env, .cache, dist, and local upload folders to .gitignore.
• Keep package-lock.json, pnpm-lock.yaml, or yarn.lock if present.
• Keep config files such as next.config.js, vite.config.ts, tsconfig.json, and vercel.json.
• Remove duplicate old apps if they confuse framework detection.

After GitHub has the right code, import the repository in Vercel. Set the root directory to the folder that contains the app. This one setting fixes many migrations where Vercel reports missing scripts even though the scripts exist in a nested folder.

Fix Replit Agent Code Before the First Vercel Build

Replit Agent is fast, but it often produces code that works in the Replit sandbox because the environment is forgiving. Vercel is less forgiving. The most common Replit Agent migration failures we see are missing scripts, mixed frameworks, invented dependencies, browser-only code used on the server, and server code that assumes a long-running Express process.

If this is eating your week, AppStuck can take it from here. The biggest time sink is not clicking the Vercel deploy button. It is untangling generated code until it behaves like a normal production app.

Normalize package scripts

Open package.json and make the scripts explicit. For a Next.js app, Vercel expects scripts like this:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  }
}

For a Vite app, the scripts usually look like this:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

If your app has "start": "node server.js" but the frontend is Vite or Next.js, check whether that server is actually required. We often see Replit Agent add Express for convenience, even when the app should be deployed as static frontend plus API routes.

Audit dependencies and imports

Run a clean install locally or in a fresh Replit shell after deleting node_modules. Generated projects frequently import packages that were never saved to package.json. Replit may appear to run because the workspace has leftover packages from previous attempts.

• Search for imports and compare them to dependencies.
• Remove packages that belong to abandoned folders.
• Move build-time tools to devDependencies only when the framework supports it.
• Pin Node version if the app relies on newer runtime features.

Add an engines field when necessary:

{
  "engines": {
    "node": "20.x"
  }
}

Use an AI prompt to find migration blockers

Paste this into Cursor, Claude, or ChatGPT: “Review this Replit project for Vercel deployment blockers. Check package scripts, framework detection, root directory, Replit-only services, environment variables, path aliases, static assets, SSR/serverless incompatibilities, and missing dependencies. Return a prioritized fix list with exact file changes.”

That prompt works best after you attach package.json, framework config, directory tree, and the full Vercel build log. Do not ask the AI to guess from a screenshot. Build logs and file structure are what reveal the real problem.

Vercel Build Failures After Moving a Replit App

When people search for replit deploy on Vercel, they often expect import, click, done. The failures usually happen after import: Vercel cannot find the framework, the build command exits with code 1, static chunks return 400, or the deployment shows a blank screen even though the build passed.

We have seen this in many Replit Agent apps where the generated code mixed Vite, Express, Next.js conventions, and custom aliases. Vercel can host all of those patterns, but not when they are tangled together without clear build output.

Build command and output directory mismatches

Check Vercel Project Settings first. Framework Preset should match the app, not the folder name. If Vercel detects “Other” for a Next.js app, the root directory is probably wrong or dependencies are missing. If it detects Vite but your output directory is set to .next, static assets will not deploy correctly.

If the build log says no output found, run the build locally and see what folder is created. Do not guess. The answer is in the filesystem after the build completes.

Static chunk 400s and broken asset paths

A common post-migration symptom is a deployed page that loads HTML but fails to load JavaScript chunks. In browser DevTools, you may see /_next/static/... or /assets/... returning 400 or 404. This often comes from an incorrect base setting, a bad asset prefix, a rewrite that catches static files, or a custom server pattern that Vercel is not using.

• For Vite, remove incorrect base values unless deploying under a subpath.
• For Next.js, avoid custom assetPrefix unless you really use a CDN.
• Check vercel.json rewrites so they do not capture static chunks.
• Make sure files referenced from code live in public or are imported through the bundler.

Bad rewrite example:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/api/index" }]
}

That kind of catch-all can accidentally route asset requests into an API handler. Use narrower routes, and let the framework serve its own static files.

Path aliases that work in Replit but fail on Vercel

Replit Agent often creates imports like @/components/Button without a matching tsconfig.json or vite.config.ts. On case-insensitive local machines, button.tsx and Button.tsx may also appear to work. Vercel builds on Linux, where case matters.

• Confirm paths in tsconfig.json.
• Confirm aliases in vite.config.ts or webpack config.
• Match import casing exactly to file names.
• Do not rely on Replit workspace-relative paths such as /home/runner/project.

For Vite, a typical alias looks like this:

import path from "path";

export default defineConfig({
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src")
    }
  }
});

Move Replit Secrets, Database, Auth, and File Storage

A successful Replit vercel migration requires moving runtime services, not just code. Many apps deploy successfully and then fail when users log in, save data, or call an API. That is usually because secrets, database URLs, auth callback URLs, or upload paths still point to Replit-era assumptions.

Vercel Environment Variables are split by environment: Production, Preview, and Development. If your app works in a preview deployment but fails after promoting to production, compare the variable sets. We have rescued apps where the production database URL was blank while preview had the correct value.

Environment variable checklist

Copy values from Replit Secrets into Vercel, but do not blindly copy every name. First confirm how the code reads each variable. Next.js browser-exposed variables must use NEXT_PUBLIC_. Vite browser-exposed variables must use VITE_. Server-only secrets should never use those prefixes.

• DATABASE_URL for Postgres, Neon, Supabase, or Prisma.
• AUTH_SECRET, NEXTAUTH_SECRET, or provider secrets.
• OPENAI_API_KEY, Stripe keys, email provider keys, and webhook secrets.
• NEXT_PUBLIC_APP_URL or equivalent public frontend URL.
• Callback URLs in Google, GitHub, Stripe, Clerk, Supabase, or Auth0 dashboards.

After adding variables in Vercel, redeploy. Environment changes do not always affect an already-built deployment.

Replace Replit DB cleanly

Replit DB is convenient, but it is not the right production database for a Vercel deployment. Choose the database based on your app’s shape. Neon or Supabase works well for relational apps. Upstash works well for Redis-style counters, rate limits, queues, and session-like data. Avoid writing user data to local files because serverless filesystems are ephemeral.

If the Replit Agent generated database code, search for Replit-specific packages and endpoints. Replace them with a standard client. For Prisma, verify schema.prisma, run migrations, and make sure the generated client is built during deploy.

npx prisma migrate deploy
npx prisma generate

If needed, add this to the build script:

"build": "prisma generate && next build"

Auth and webhooks after the domain changes

Authentication often fails after the move because the provider still trusts the Replit URL. Update allowed origins, redirect URLs, webhook endpoints, and cookie settings. If cookies are marked secure or bound to an old domain, login loops can happen even when the code is correct.

• Replace https://your-repl.replit.app with your Vercel or custom domain.
• Update OAuth redirect URLs for every provider.
• Regenerate webhook secrets if you create new webhook endpoints.
• Check CORS rules for API routes and external backends.

This is also the moment to remove hardcoded development URLs. A production app should derive URLs from environment variables, not from strings generated during the first Replit prototype.

Handle Next.js, SSR, Express, and API Route Mismatches

The hardest move Replit app to Vercel cases involve server rendering. A normal Next.js app maps well to Vercel. A normal Vite static app maps well too. The messy middle is a Replit Agent app that uses “express to do SSR,” serves static middleware manually, or combines a custom Node server with frontend routing.

Vercel can run serverless functions, but it is not the same as keeping one Express server alive forever. Long-lived processes, WebSocket servers, local background workers, and in-memory queues need redesign. This is where many migrations look almost finished but keep failing under real usage.

When to keep Next.js as Next.js

If your app is already a Next.js project, remove unnecessary custom server code unless it is essential. Use app/api or pages/api for API routes. Use server components, route handlers, or server actions according to the version you are on. Keep the Vercel preset as Next.js and avoid overriding output settings unless you know why.

• Do not set a custom output directory for a standard Next.js app.
• Keep next, react, and react-dom versions compatible.
• Remove old Express static serving if Next.js handles assets.
• Check next.config.js for experimental options generated by AI.

If the app uses file uploads, do not write uploads into the project directory. Use Vercel Blob, S3, Cloudinary, Supabase Storage, or another external storage provider.

When Express SSR needs refactoring

For apps built as Express plus Vite SSR, Vercel may not output static files the way you expect. The common complaint is that the build does not output any files except a static middleware file, or that the server starts locally but Vercel cannot serve it. That is a structure problem, not a Vercel outage.

You have three realistic options:

1. Convert to Vite static if SSR is not actually needed.
2. Convert server endpoints to Vercel functions and keep the frontend static.
3. Move the backend to Render, Fly.io, Railway, or another Node server host while Vercel serves the frontend.

We usually recommend splitting frontend and backend when the Express server does real backend work. Vercel is excellent for frontend and serverless workloads, but forcing a stateful Express app into serverless can create new production bugs.

Use vercel.json only when necessary

AI-generated projects often include a vercel.json that makes things worse. If Vercel already detects your framework, delete unnecessary overrides first. Add configuration only for specific needs like function duration, clean rewrites, or custom builds.

{
  "functions": {
    "api/**/*.ts": {
      "maxDuration": 30
    }
  }
}

Keep rewrites narrow, test static assets after every change, and redeploy from a clean commit. If one config file tries to make Vite, Next.js, and Express all happy, it usually makes none of them reliable.

When to Call in AppStuck

DIY is worth it when the app is small, the framework is clear, and the first Vercel build log points to one obvious issue. It stops being worth it when every fix reveals another generated-code problem. If you have already changed build commands, moved environment variables, edited aliases, and still have a blank screen or failing auth, the migration is no longer a simple export.

At AppStuck, we specialize in rescuing apps built with AI and no-code tools, including Replit, Lovable, Bolt.new, Cursor, Base44, FlutterFlow, Bubble, Webflow, and Builder.ai. We have fixed 300+ broken AI-generated apps over 18 months, and Replit-to-Vercel failures are one of the most repeatable patterns we see.

Signs the migration needs expert help

• Vercel builds pass, but production shows a white screen.
• Static chunks, images, or CSS return 400 or 404.
• GitHub import works, but Vercel builds the wrong folder.
• Replit Agent created multiple app folders and nobody knows which one is live.
• Auth works on Replit but loops or fails on the Vercel domain.
• Database reads work locally but fail in production.
• The app uses Express SSR, WebSockets, file uploads, or background jobs.

What we usually fix first

We start by reproducing the failure from a clean checkout, then compare Replit runtime assumptions against Vercel’s build and runtime model. That prevents random config changes. The fix might be as small as correcting root directory and aliases, or as large as splitting a backend out of a Replit monolith.

1. Identify the real framework and root directory.
2. Normalize scripts, dependencies, and Node version.
3. Move secrets, database, auth, and storage to production services.
4. Fix build output, static assets, and routing.
5. Deploy, test, and document the production setup.

If your Replit export to Vercel is blocked and you need the app working instead of endlessly debugging build logs, send it to AppStuck. We will tell you whether it is a quick rescue, a migration cleanup, or a backend architecture issue before you spend another week guessing.