Why can’t I just email the folder to people?

They would need your exact software versions, dependencies, database, and secrets. A hosted URL works for anyone with a browser — that is the whole point of going online.

Many platforms have free tiers for small projects and hobby traffic. Databases, heavy usage, or always-on workers may eventually cost money. Read the pricing page before you depend on it for a business.

Do I need a credit card to deploy?

Some hosts require a card even for free tiers; others do not. Railway, Render, and Vercel policies change — check current signup requirements.

How do I update the app after it is online?

Change code locally, commit and push to GitHub. Most hosts auto-deploy on every push to main. Your live URL updates after the build finishes.

What if I use a database locally?

Local SQLite files do not move to the cloud automatically. Production usually needs a hosted database (Railway Postgres, Supabase, etc.) and a DATABASE_URL variable pointing to it.

Guides

How to Put a Local App Online (Beginner Guide)

A local app runs only on your machine. When you close your laptop or stop the dev server, nobody else can use it. Putting your app online means hosting it on a server that stays running 24/7 and gives you a public URL anyone can open in a browser. This guide explains that path in plain language — from your project folder to a live link — without assuming you already know Git, DNS, or cloud jargon.

Updated July 2026 · 9 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

To put a local app online: upload your code to GitHub (using GitHub Desktop if you prefer), pick a hosting platform that matches your stack, set environment variables on the host, deploy, and test the live URL. A custom domain is optional.

Best for

First-time makers with a project folder that runs locally

First step

Upload to GitHub — GitHub Desktop is fine, no terminal required

Main risk

Deploying secrets or skipping env vars on the host

What MakerToLaunch checks

Safe upload, missing env docs, and deploy blockers before go-live

Who this is for

Your app works when you run it locally but you want a shareable internet URL
You are new to GitHub, hosting, and environment variables
You built with AI tools or tutorials and need the “what comes next” steps
You want to avoid common first-deploy mistakes like leaking .env files

What you'll need

A project folder that runs locally without errors
A free GitHub account
A hosting account (Vercel, Railway, Render, Netlify, etc. — many have free tiers)
Your environment variables listed in .env.example or README
Roughly 45–90 minutes for your first deploy

Key concept

What “online” actually means

When developers say an app is “online” or “in production,” they mean it runs on a remote computer — a server — that is connected to the internet all the time. Your hosting provider manages that server (or serverless runtime) for you. You upload code; they build it, run it, and hand you a URL.

A local app depends on your machine: your Node version, your database file, your .env secrets, your Wi-Fi. An online app depends on the host’s environment. That is why deployment is more than copy-paste — you must tell the host how to build, start, and configure your app.

Being online does not automatically mean the whole world will find you. It means anyone with the URL can reach your app. You control whether you share that link quietly with friends or post it publicly.

Deploy settings

Why GitHub comes first

GitHub stores your code in the cloud with version history. Modern hosting platforms deploy by pulling from a GitHub repository. When you fix a bug, you push an update to GitHub and the host rebuilds — no manual zip uploads every time.

GitHub is also backup. If your laptop dies, your project still exists. It is the standard handoff point between “on my computer” and “on the internet.”

Before uploading, run a safe-upload check. GitHub is not a place for .env files, API keys, or multi-gigabyte node_modules folders. Use .gitignore and verify your repo on github.com after the first push.

Hosts connect to GitHub with a few clicks
Every deploy reads from a specific branch (usually main)
Private repos work with most hosts — your code does not have to be public

Deploy settings

Upload with GitHub Desktop (no terminal)

If the command line feels intimidating, use GitHub Desktop. Download it from desktop.github.com, sign in with your GitHub account, and click “Add local repository.” Select your project folder.

If GitHub Desktop says the folder is not a Git repository, choose “create a repository” in that folder. Review changed files in the left panel — make sure .env and node_modules are not listed. Write a short commit message like “Initial commit” and click “Commit to main.”

Click “Publish repository.” Choose a name, decide public vs private, and publish. Open the repo on github.com in your browser and confirm the file list looks right before connecting a host.

Install GitHub Desktop and sign in
Add your local project folder
Verify .env is not in the commit list
Publish to GitHub and check the remote repo in your browser

Deploy settings

Choose hosting based on your stack

Different frameworks fit different hosts. There is no single “best” platform — there is a best match for what you built.

Static sites and many Next.js apps deploy easily to Vercel or Netlify. Python Django or Flask apps often go to Railway or Render. Node APIs with PostgreSQL commonly use Railway, Render, or Fly.io. When unsure, search “deploy [framework name] free tier” and pick a guide aimed at beginners.

Most hosts auto-detect settings for popular frameworks. If auto-detect fails, you will need a build command (e.g. npm run build) and a start command (e.g. npm start or gunicorn). Check your README or package.json.

Next.js / React static → Vercel, Netlify
Django / Flask / FastAPI → Railway, Render
Node API + database → Railway, Render
Simple HTML/CSS → Netlify, GitHub Pages, Cloudflare Pages

Key concept

Environment variables on the host

Your local .env file does not travel with GitHub — that is intentional. Secrets stay off public code. When you deploy, you copy each variable name and value into your hosting dashboard under Environment Variables or Secrets.

Variable names must match exactly what your code expects. A typo like DATABASE_URL vs DB_URL will cause “works locally, broken online” bugs. Use .env.example as your checklist — it lists names without real values.

Some variables are “public” (prefixed NEXT_PUBLIC_ in Next.js) and get baked into frontend bundles. Still set them on the host. Never put secret keys in NEXT_PUBLIC_ variables.

Open .env.example and copy every variable name
Paste name + production value into host dashboard
Redeploy after adding or changing variables
Never commit real .env files to GitHub

Custom domain (optional for now)

Every host gives you a free subdomain like your-app.vercel.app or your-app.up.railway.app. That URL is fully functional for testing, demos, and early users. You do not need to buy a domain on day one.

When you are ready, purchase a domain from a registrar (Namecheap, Google Domains, Cloudflare, etc.) and follow your host’s “custom domain” instructions. You will add DNS records that point your domain to the host.

DNS changes can take minutes to 48 hours to propagate. If your domain does not work immediately, wait and double-check the records your host provided.

Watch out

Common deploy errors and what they mean

Build failed / Module not found: Often a missing dependency in package.json or wrong Node/Python version. Check the host’s runtime settings and ensure package.json lists all imports.

Application failed to respond: Start command may be wrong, or the app listens on the wrong port. Many hosts expect process.env.PORT — your AI-generated server code may need a small fix.

500 errors on live site but works locally: Usually missing environment variables or a different database in production. Compare .env.example against what you set on the host.

Blank page after deploy: Check browser console for JavaScript errors. For SPAs, confirm the host is configured for client-side routing. Build logs may show warnings you missed.

Read the deployment log line by line — the last error is usually the real one
Fix locally, push to GitHub, let the host redeploy
Compare local .env keys with host dashboard one by one
Search the exact error message — someone else has hit it before

GitHub vs hosting vs domain

Criteria	GitHub	Hosting	Domain
Job	Store code + version history	Run your app 24/7 on the internet	Custom name like myapp.com (optional)
Required for launch?	Yes — almost always	Yes	No — free host URL works first
What you get	Repo URL on github.com	Live URL like *.vercel.app	Branded URL you choose
When to set up	Before first deploy	After GitHub upload	After deploy works on free subdomain

Common mistakes

Deploying without uploading to GitHub first
What happens: Most beginner hosts cannot pull from your laptop — deploy stalls or requires manual zip uploads every time.
How to fix it: Create a GitHub repo and push your code. Nearly every beginner-friendly host expects it.
Forgetting to set environment variables on the host
What happens: The live app crashes or returns 500 errors while everything works on your machine.
How to fix it: Treat .env.example as a copy-paste checklist for the hosting dashboard.
Uploading node_modules to GitHub
What happens: Huge repo, slow pushes, and sometimes broken deploys — hosts install deps themselves.
How to fix it: Add node_modules/ to .gitignore. The host installs dependencies during build.
Buying a domain before the app deploys successfully
What happens: You pay for a domain while still debugging deploy errors on the free host URL.
How to fix it: Use the free host URL until deploy works. Add a custom domain once you are confident.

Copy-ready prompt

Prompt: plan my first deploy

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

I have a local app and want to put it online. Review this project and tell me:

1. What framework/stack you detect and which hosting platform fits best (Vercel, Railway, Render, etc.).
2. Every environment variable I need in production and create .env.example if missing.
3. The exact build and start commands for deployment.
4. Any localhost URLs, debug settings, or secrets that would break a public deploy.
5. A ordered checklist from GitHub upload through first successful deploy.

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready check

Before you deploy

Work through these checks before you connect a host.

App runs locally
.gitignore and safe-upload review complete
Code on GitHub — verified in browser
Hosting platform account created
Correct host chosen for your framework
GitHub repo connected to host
All environment variables set on host
Deploy succeeded — live URL opens
Main features tested on live URL

Frequently asked questions

Why can’t I just email the folder to people?: They would need your exact software versions, dependencies, database, and secrets. A hosted URL works for anyone with a browser — that is the whole point of going online.
Is hosting free?: Many platforms have free tiers for small projects and hobby traffic. Databases, heavy usage, or always-on workers may eventually cost money. Read the pricing page before you depend on it for a business.
Do I need a credit card to deploy?: Some hosts require a card even for free tiers; others do not. Railway, Render, and Vercel policies change — check current signup requirements.
How do I update the app after it is online?: Change code locally, commit and push to GitHub. Most hosts auto-deploy on every push to main. Your live URL updates after the build finishes.
What if I use a database locally?: Local SQLite files do not move to the cloud automatically. Production usually needs a hosted database (Railway Postgres, Supabase, etc.) and a DATABASE_URL variable pointing to it.