DEV Community

Cover image for Your AI-built app works locally but breaks when you deploy it? Check these 6 things
Infrly
Infrly

Posted on

Your AI-built app works locally but breaks when you deploy it? Check these 6 things

#ai #webdev #beginners #automation

You built an app with Cursor, Claude Code, Lovable or Bolt. On your laptop it's perfect. You deploy it, and you get a blank page, a 502, or a login button that spins forever.

We run a small deployment platform, so we watch a lot of first deploys. Most of the failures we see happen before the app even starts, and the causes repeat. None of them mean the AI wrote bad code. They're the gap between "runs on my laptop" and "runs on a server", and AI tools rarely close that gap for you.

Here are the six we see most, with the fix for each.

1. The frontend still calls localhost

While you built the app, the API ran on your machine, so the AI wired the frontend to it:

const res = await fetch("http://localhost:3000/api/todos");
Enter fullscreen mode Exit fullscreen mode

In production, localhost means the visitor's own computer. Every request fails, and the browser console fills with ERR_CONNECTION_REFUSED.

Fix: read the API address from configuration and set it per environment.

const API_URL = import.meta.env.VITE_API_URL; // e.g. https://api.example.com
const res = await fetch(`${API_URL}/api/todos`);
Enter fullscreen mode Exit fullscreen mode

2. Frontend variables are baked in when you build

VITE_…, NEXT_PUBLIC_… and REACT_APP_… variables aren't read at runtime. They're copied into your JavaScript at build time. If you add or change one on the server after the build, nothing happens.

Fix: set them before the build runs on your hosting platform, then rebuild and redeploy.

3. The server listens on the wrong address or port

This works on your laptop:

app.listen(5000);
Enter fullscreen mode Exit fullscreen mode

On a hosting platform, your app has to listen on all interfaces and on the port the platform gives it, usually in the PORT variable. Otherwise the platform's health check can't reach it, and the deploy fails or times out.

Fix:

const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0");
Enter fullscreen mode Exit fullscreen mode 
# Python / FastAPI
uvicorn main:app --host 0.0.0.0 --port $PORT
Enter fullscreen mode Exit fullscreen mode

4. The database didn't come with you

Locally you had a SQLite file or a Docker Postgres with your test data. In production there's an empty database, or none at all, and your tables don't exist yet.

Fix: create a production database, set DATABASE_URL to it, and run your migrations against it, either as part of the deploy or once by hand:

DATABASE_URL="postgres://…" npx prisma migrate deploy
# or: alembic upgrade head
Enter fullscreen mode Exit fullscreen mode

5. CORS blocks the frontend

Frontend on app.example.com, API on api.example.com: the browser refuses the API's responses unless the API says that origin is allowed. The error looks like a network failure, which makes it confusing.

Fix: allow your frontend's production domain in the API's CORS settings. If you use cookies, list the exact domain instead of *:

app.use(cors({ origin: "https://app.example.com", credentials: true }));
Enter fullscreen mode Exit fullscreen mode

6. Secrets ended up in the frontend

Anything in frontend code is public: anyone can open the browser's dev tools and read it. To "make it work", AI tools sometimes put a service key or a third-party API key straight into the frontend.

Fix: keep secrets on the server and call third-party APIs from your backend. If you use Supabase, only the anon key belongs in the frontend, and Row Level Security must be on for every table. In 2025, a missing-RLS pattern exposed user data in more than 170 AI-built apps (CVE-2025-48757).

The 60-second checklist

Before your first deploy:

  • [ ] No localhost left in frontend code
  • [ ] Frontend variables set before the build
  • [ ] Server listens on 0.0.0.0 and $PORT
  • [ ] DATABASE_URL set and migrations run
  • [ ] CORS allows your production domain
  • [ ] No secrets in the frontend bundle

If your deploy still fails, read the build log from the top, not the bottom. The first error is usually the real one; everything after it is fallout.

What broke your first deploy? Tell us in the comments. We'll add the common ones to this list.

We build Infrly, which deploys GitHub repos as web services, static sites, cron jobs, PostgreSQL and Key Value, and is free during its public beta. This list comes from watching first deploys fail. This article was written with AI assistance and checked by us.

Top comments (0)