Your AI-generated app works locally but not when deployed: 6 checks before you ship
AI tools like Lovable, Bolt, Cursor and Replit can generate a working app in an afternoon. Then you deploy it and it fails in a way that never showed up on your laptop. The code is rarely the problem. The problem is the
AI tools like Lovable, Bolt, Cursor and Replit can generate a working app in an afternoon. Then you deploy it and it fails in a way that never showed up on your laptop. The code is rarely the problem. The problem is the gap between "runs on my machine" and "runs in a container on someone else's server".
Here are the six checks that catch most first-deploy failures. Each one takes a minute, and each one is a real reason a freshly generated project does not start.
1. Does the project have a real start command?
A hosting platform needs to know how to start your app. Generated projects often only have a dev script.
For a Node.js project, check package.json:
{
"scripts": {
"dev": "vite",
"build": "vite build",
"start": "node server.js"
}
}
If there is no start script, many platforms cannot launch the project. A Vite or Create React App result is a static site, so either serve the built folder or deploy it as static files:
"start": "npx serve -s dist -l $PORT"
For Python, the equivalent is a clear entry point (main.py) and a requirements.txt. For Go, Rust or .NET, expect to need a Dockerfile, because there is no file the platform can guess a build from.
2. Does it listen on the right port and host?
On your laptop, localhost:3000 is fine. In a container, the platform tells you the port through an environment variable, and the app must listen on all interfaces, not only on 127.0.0.1.
// Node / Express
const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0");
# FastAPI
# uvicorn main:app --host 0.0.0.0 --port ${PORT:-8000}
A hard-coded port, or a server bound to 127.0.0.1, looks perfectly healthy in the logs and is unreachable from outside.
3. Are all environment variables defined where the app runs?
Generated code reads secrets from the environment, and your local .env file is not shipped with the project (and should not be). List every variable the code reads:
grep -rnE "process\.env\.[A-Z_]+|os\.environ(\.get)?\(|os\.getenv\(" --include=*.js --include=*.ts --include=*.py .
Two traps are worth knowing:
- Use uppercase letters, digits and underscores for names. Some platforms reject anything else.
- In Vite, only variables prefixed with
VITE_reach the browser, and they are baked in at build time. If the value is missing during the build, the deployed site showsundefinedand no error appears anywhere.
4. Do the dependencies install in a clean environment?
AI-generated Python code regularly imports packages that never made it into requirements.txt, because the tool installed them in your session. Test in a clean environment before uploading:
python -m venv /tmp/check && . /tmp/check/bin/activate
pip install -r requirements.txt
python main.py
For Node, run npm ci in a fresh clone. If it fails or the app crashes on a missing module, the deploy would have failed the same way.
5. Where does the app write data?
Container filesystems are disposable. A SQLite file written to a relative path next to your code can disappear on the next redeploy, and an empty database can silently replace the real one. Put persistent data in the directory your platform keeps across restarts (on Deployka that is /data), and make the path configurable:
import os
DB_PATH = os.environ.get("DB_PATH", "/data/app.db")
6. Are there secrets inside the project?
AI tools sometimes hard-code a key to make the demo work. Search before you zip or push:
grep -rnE "sk-[A-Za-z0-9]{20,}|BOT_TOKEN\s*=\s*['\"]|api[_-]?key\s*=\s*['\"]" .
If a key was ever committed, rotate it. Deleting it from the latest commit does not remove it from the history.
Bonus for Telegram bots: polling or webhook, not both
If a webhook is set for your bot and your code starts long polling, Telegram answers with a conflict error. Either remove the webhook (deleteWebhook) or use webhooks consistently. This is one of the most common "my bot does nothing after deploy" causes.
Doing the checks automatically
Running these by hand is fine once. Doing it for every project gets old. That is why I added a pre-build scan, Deploy Doctor, to Deployka, the hosting service I build for Telegram bots, web apps, APIs and AI projects. It looks at your project for the usual blockers (missing environment variables, a missing start command, configuration problems) before the build starts, and it is made with projects from Lovable, Bolt, Cursor and Replit in mind. The scan is free.
If you want to try a deploy without paying, there is a free plan with no card required (128 MB RAM, one project; check the site for current limits). You can upload a ZIP or connect a GitHub repository, add your secrets, and read the logs from the dashboard. Whichever platform you use, the six checks above are worth the minute.
What is the most confusing deploy failure an AI-generated project gave you? I am collecting these for the next checks.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.