How to deploy a web app, step by step

What deploying a web app means

On your computer the app talks to localhost, uses a database file or a local database, and stops when you close the laptop. Deploying moves it to a server that stays on, gives it a public address with HTTPS, connects it to a real database and restarts it if it crashes.

Check these before you deploy

1. It runs without errors on your computer, including after a fresh start.
2. It listens on the port it is given, not a fixed one. Servers pass the port in an environment setting.
3. Nothing is hard-coded to localhost. Addresses for the database, cache and your own API must come from settings.
4. Secrets are not in the code. API keys and passwords belong in environment settings.
5. Data lives in a real database, not a file next to the app. A file database breaks as soon as two copies of the app run.
6. Uploaded files go in one shared folder that survives restarts, not in the app’s own folder.
7. You have a backup of the code, files and database.

Four ways to deploy a web app

More detail: Vercel, Render, Railway and your own server.

Deploy a web app with Project3000

1. Create your account at project3000.io with Google or email, and we recommend turning on two-factor sign-in (it takes a minute).
2. Make sure your app works on your computer, without errors, and back it up. The dashboard asks you to confirm both before it gives you the prompt.
3. Choose a package and create the app. Its name becomes its address: your-name.apps.project3000.io.
4. Open your AI tool on your project folder, with approval turned on, so it asks before it runs each command. The “See how” links in the dashboard show where both settings are.
5. Copy the prompt from your dashboard and paste it into your AI tool. It reads your project, adds the two files Project3000 needs (a Dockerfile and a manifest.json), connects the app to its included database and cache, runs the app to check it works without errors, and uploads it. Approve each step when your AI tool asks.
6. Click Deploy. Your app goes live on its own HTTPS link and runs as two copies on separate servers. Share the link with anyone.

Mistakes that break a first deploy

• “It works locally” but the page is blank. The frontend still calls localhost for the API. Use relative addresses or a setting.
• The app starts and stops. It listens on a fixed port, or crashes because a required setting is missing.
• Data disappears after a restart. It was stored in a local file or in the app’s own folder.
• Login sessions break with two copies. Sessions kept in one process’s memory are not shared. Keep them in the cache or database.
• The build fails. A dependency is missing from the lock file, or the build step was never run.

With our prompt your AI finds and fixes most of these before it uploads, because it runs the same checks our servers run.

After your web app is live

• Ship updates with the redeploy prompt. Your data stays, and the live version keeps running if the new one fails to start.
• Add your own domain on Pro or Business: domain guide.
• Keep your own backups. Why and how.

Prices

Prices in US dollars, before VAT or sales tax. Billed monthly per app; cancel anytime from your dashboard.