Why your AI app works in preview but not live

Your AI app answers perfectly in the preview, then falls over the moment you deploy it. That is frustrating because nothing feels “broken” until real users, a real domain, and a real server get involved.

Short version: when an ai app works in preview not live, the code is usually not the only thing that changed. The live version often has different environment variables, permissions, domains, HTTPS rules, memory limits, or background-job behavior than the preview version.

Why does an AI app work in preview but not live?

A preview is like cooking in your own kitchen. You know where the salt is, the stove is already on, and nobody is waiting at a table.

Live deployment is a restaurant. The same recipe now depends on a front door, a public address, staff timing, storage, security checks, and enough room to serve more than one person.

For AI apps, the most common live failures are not mysterious. They are usually one of these:

• The OpenAI API key, Anthropic API key, or other secret is missing in production.
• The app is calling the wrong backend URL.
• The live domain is blocked by CORS, which is the browser rule that decides which websites may talk to which servers.
• HTTPS is missing or wrong, so the browser refuses requests.
• The server runs out of memory while loading a model, processing a file, or streaming a long response.
• A background task works in preview but is not actually running live.

The visible error may be vague: “500 Internal Server Error”, “502 Bad Gateway”, “CORS error”, “Missing API key”, or “Unauthorized”. The cause is often much more ordinary than the message sounds.

What changes between preview and production?

Preview tools try to be kind. They often fill in local values, keep processes warm, and show helpful errors.

Production is stricter. It only knows what you explicitly gave it.

Environment variables are the classic example. These are private settings your app reads at runtime, such as OPENAI_API_KEY, DATABASE_URL, or NEXT_PUBLIC_API_URL. In preview, those values may exist on your laptop or inside the builder. Live, they must exist on the server in the place the app actually runs.

Domains also change. In preview, your frontend might call localhost or a temporary URL. Live, it must call the real backend address. If the app still points at a preview address, your users may see a blank chat, endless loading, or a failed request in the browser console.

Then there is the difference between build time and runtime. Build time is when the app is packaged. Runtime is when a user actually opens it. Some AI apps accidentally bake the wrong value into the build, then keep using it after deployment.

If the app is deployed with containers, this gets easier to repeat but not automatically easier to understand. If Docker is still fuzzy, this plain-English Docker guide helps explain the box your app may be running inside: /blog/docker-on-server-for-beginners.

Why do AI apps fail more often than simple websites?

A normal brochure site mostly serves pages. An AI app talks to outside services, waits for long answers, streams partial text, stores user messages, and sometimes handles uploads.

That gives it more moving parts.

Think of a simple website as a light switch. Think of an AI app as a coffee machine connected to a payment terminal, water line, grinder, and receipt printer. If one connection is wrong, the whole experience looks broken.

Common AI-specific problems include:

• Long responses hitting a timeout before the model finishes.
• Streaming replies working in preview but being buffered or cut off live.
• File uploads being stored in a temporary folder that disappears after restart.
• Vector databases or embeddings not being reachable from the live app.
• Rate limits from OpenAI, Anthropic, Replicate, or another API provider.
• Memory spikes when parsing PDFs, images, audio, or large prompts.

If the whole server feels slow or the app only fails under real traffic, the issue may be resource pressure rather than a bad deployment. CPU, RAM, disk, and traffic are explained in plain language here: /blog/why-is-my-server-slow.

How do you tell whether the problem is code, server, or domain?

Start by separating the layers. A live AI app is usually three things stacked together: the domain, the web app, and the outside AI service.

If the domain does not reach the server, the app never gets a chance to run. You may see a browser timeout, DNS error, or the wrong site. Domain pointing and HTTPS need to be correct before deeper debugging matters. If this is the part that feels unclear, see /blog/point-a-domain-at-your-server and /blog/free-https-on-your-server.

If the page loads but the chat or AI feature fails, look at the app layer. A “500 Internal Server Error” usually means your own backend crashed. A “401 Unauthorized” or “Missing API key” points toward secrets or provider access. A browser “CORS error” usually means the frontend and backend do not agree on who is allowed to talk.

If the app starts working and then dies during larger prompts, file uploads, or busy periods, suspect capacity. The server may not have enough memory, or the app may be doing heavy work in the same process that serves users.

The important part is not to change five things at once. When preview works and live does not, you are looking for the one difference that production introduced.

FAQ

Does “works in preview but not live” mean my code is bad? Not necessarily. It often means the live environment is missing a value, permission, domain rule, or running process that preview had.

Why do I get “502 Bad Gateway” after deploying? “502 Bad Gateway” usually means the public web server cannot reach your app process. The app may have crashed, failed to start, or be listening in the wrong place.

Why does my AI chat load forever in production? Common causes are a wrong API URL, a missing model provider key, a blocked browser request, or a timeout during a long response.

Can HTTPS break an AI app? Yes. Browsers can block requests when a secure page tries to call an insecure endpoint, or when the certificate is wrong or expired.

The shortcut

Server Manager helps by keeping the live setup readable instead of turning it into a pile of half-remembered fixes. The outcome is simple: months later, you can still see which app belongs to which domain, what it depends on, and where the important live pieces are supposed to fit.

That matters for the exact failures above. A missing API key, a wrong public URL, an expired certificate, one project breaking another, or an app that quietly outgrew the server are all easier to spot when the deployment is not hidden in scattered notes and one-off terminal history.

The real benefit is not avoiding every problem. It is making production boring enough that when your AI app works in preview but not live, you have a clear place to look instead of guessing.

What does “fixed” look like?

Fixed does not just mean the page loads once. It means the live app behaves like the preview for the things users actually do: send prompts, receive streamed answers, upload files, sign in, and come back tomorrow to the same data.

You win when the live version has the right secrets, the right domain, working HTTPS, enough room to run, and a setup you can still understand later. Then deployment stops feeling like a cliff edge and becomes just the next place your app runs.