Where to host your first project
A project running in an editor is not necessarily a project that stays online. Hosting serves your files or runs your application when visitors arrive. Choose it by the kind of project you built and the responsibilities you are prepared to own, rather than collecting a stack before you know what the project needs.
What you’ll take away
- Work out whether the project is static or needs a running backend.
- Use an account-owned host and a repeatable update process.
- Verify the public URL, not just the editor preview.
Find out what needs to run
A static project can be served as files: HTML, CSS, JavaScript, images and other assets. A portfolio, many browser games and a calculator that runs on the visitor’s device can fit this model. A build step may turn source files into the final folder the host needs; static does not mean the page cannot be interactive.
A backend is code that runs away from the visitor’s browser. You may need one to protect an API secret, process payments, manage shared data or run a long task. A database stores durable information; it is a separate responsibility even when your building platform offers it in the same dashboard. Ask your agent to identify which parts of your project run where.
A prompt to adapt
Select and copy this brief, then replace the details with your own.
Inspect this project without deploying it. Is it static, does it need server functions, or does it need a continuously running backend? Identify the framework, build command, output folder, runtime requirements, environment variable names and data-storage dependencies. Do not print secret values. Recommend two compatible hosting routes and explain what I would maintain on each.Compare the routes by the job
The table is a starting point, not a price ranking. Plans, quotas, commercial-use terms and available features change. Check the linked documentation against the actual project before choosing. A host that suits a personal portfolio may be unsuitable for a paid service.
Scroll to see all columns →
| Route | A useful fit | Check before publishing |
|---|---|---|
| ChatGPT Sites | A supported Sites-built website or lightweight app | Audience controls, workspace access and current hosting limits |
| Replit publishing | A Replit project you want to publish from the same environment | Correct deployment type, persistent storage and ongoing usage |
| Vercel | Web projects with supported frameworks and Git-based updates | Build settings, server behavior, plan terms and production domain |
| GitHub Pages | Portfolios, documentation and suitable static projects | No general backend; restrictions on business/commercial SaaS hosting |
| Netlify | Static sites and supported application/function workflows | Build/output folder, functions and current usage terms |
| Cloudflare Workers | New projects using Cloudflare’s application platform | Framework compatibility, bindings and data services |
| Render | Applications needing a running web service | Start command, runtime, database and service behavior |
Notice what a preview hides
A preview may depend on your development session, an authenticated workspace or temporary sample data. Publishing usually creates a separate build or snapshot. Replit explicitly distinguishes the running published app from the editor; changes need to be published to reach visitors. With a Git-connected host, check which branch produces production and which changes create previews.
GitHub Pages serves static files and has important usage restrictions: it is not a general free host for an online business or commercial SaaS. Cloudflare’s current Pages documentation points new projects toward Workers. These are examples of why an old “free hosting” list can be a poor guide to a product you intend to keep running.
Set up a path you can repeat
Create the project under an account you own and record its source location. Set the build command and output folder from the project, not from an unrelated tutorial. Add server-side environment variables through the host’s protected settings. A value shipped in browser JavaScript is visible to visitors; calling it an environment variable does not make it secret.
Publish first on the host-provided URL. Once the build works, attach a custom domain if you need one. Follow the exact DNS records the host provides, preserve unrelated mail records, and wait for the provider to confirm HTTPS. Choose one canonical address so your links, analytics and sharing metadata agree.
Prove that the live version is usable
Open the live link signed out. Try its main task, reload an inner page, follow a shared project link and check a deliberately unknown path. Verify that images load and that a form really saves or delivers its result. A green build badge proves a build finished; it does not establish that the product works for a visitor.
Make one small follow-up change and publish it. Confirm it appears at the same public address. Then find the previous deployment and learn the rollback path before you need it. Save a short operations note with the host, source, production branch, domain account, update instructions and support contact. This note is part of the project, especially if an agent helped you build it.
Before you move on
- The chosen route supports every required runtime and data service.
- Production belongs to your account and has a stable URL.
- Secrets are kept out of public files.
- A signed-out visitor can use the main feature.
- You have successfully published an update and located rollback.
Sources
Official documentation and original sources used for this guide. Product features and availability can change; check the linked source before choosing a plan or publishing.
- Vercel deployment documentation vercel.com
- Replit publishing docs.replit.com
- GitHub Pages usage restrictions docs.github.com
- Cloudflare Workers developers.cloudflare.com
- Render web services render.com
- ChatGPT Sites help help.openai.com