How to publish a website from localhost

A website that opens on localhost is available only on the computer running it. To let other people visit, publish every part of the project on a service reachable over the Internet. Choose hosting based on what must run, not on the editor or AI tool that generated the code.

If you have AI-generated HTML, see the HTML and CSS publishing guide. For React and Vite, follow the Git deployment walkthrough. If Codex created the project, compare ChatGPT Sites and repository-based publishing before choosing a destination.

1. Identify what sits behind the page

Inspect the project folder, package.json, documentation and scripts. Note whether it contains:

• Static files: HTML, CSS, images and perhaps JavaScript downloaded by the browser. Some React/Vite and Astro projects also produce static files during a build.
• A server process: an API, request-time rendered pages, custom authentication, background jobs or a Node/Python service.
• External services: a database, file storage, email, login or APIs. A page that renders does not prove those integrations are connected.

A development server such as npm run dev is for working on your computer. It is not the public version. Check the framework’s build command and output directory; Vite, for example, usually creates dist, but its configuration can change that (Vite documentation).

2. Save and prepare the project

Put the code in a Git repository and keep a copy before changing its configuration. Do not publish .env files, passwords, private keys or real customer data. Search for localhost, paths on your disk and test URLs; on a public website, localhost points to each visitor’s own device.

If the folder is not in Git yet, add ignore rules for dependencies and secrets to .gitignore first, for example:

node_modules/
.env
.env.*
!.env.example

From the project folder, initialize and review the repository before your first commit:

git init -b main
git add .
git status --short
git commit -m "Initial version"

If git status shows a key, an .env file or private data, do not commit: unstage it and correct .gitignore. This rule does not stop tracking files Git already knows about. Then create an empty repository—private if the code belongs to a client—and connect its URL:

git remote add origin https://github.com/USERNAME/REPOSITORY.git
git push -u origin main

If the folder already contains .git, do not initialize a nested repository: check the branch and remote with git branch --show-current and git remote -v. GitHub’s guide to adding locally hosted code covers other variants. Then connect the repository to Hostbrid Projects; the Projects manual explains permissions and repository selection.

If the project is a monorepo, record which directory contains the app and which files it needs during install and build. Do not remove an API, server folder or integration just to make the homepage appear to work.

3. Choose where each component should run

For HTML, CSS and other static files, you need hosting that serves those files and lets visitors open their public routes. Hostbrid Sites covers managed websites such as WordPress; check its catalog and limits for your specific project.

For a repository that needs a build and Git deployment, look at Hostbrid Projects. Projects also runs Docker services within plan quotas: Dev publishes static projects, while persistent services require a paid plan. Check the Projects plans and prices for service counts and available resources before ordering. A static build does not run a Node API your application depends on.

Consider a VPS if you need root access, operating-system control, network configuration or processes that do not fit within Projects plan limits. On a VPS, you manage the operating system, updates, security, backups and deployments. Compare current plans and prices with actual requirements, not just the size of the project folder.

4. Configure builds, variables and data

Set the install command, build command and output directory for your framework. Frontend variables can end up inside files delivered to browsers; never put secrets there. Keep private keys on the server and configure them as protected environment variables.

If you use a local database, migration means moving its schema and data through an appropriate process and changing the production connection. Publishing code does not automatically copy SQLite or another database from your laptop. Read how to prepare a PostgreSQL migration before connecting real data.

A form also needs a destination that accepts and processes submissions. See how to verify its backend and delivery; a “sent” message on screen does not prove that an email arrived.

5. Test the public version before announcing it

Open the HTTPS URL from another device and test the homepage plus an internal route pasted directly into the address bar. Check images, styles, console errors, links, login, forms and the API calls your project actually uses. If you change a build variable, rebuild: editing it later does not change files already published.

Connect your domain after the temporary version works. Set the DNS records your provider gives you, wait for propagation and check the HTTPS certificate. Keep the previous website available until you have tested the new one, and retain a way to roll back.

What to buy for your project

HTML or a compiled frontend with no server: check destinations that support those files and routes. A Git build or Docker service within plan quotas: review Projects and its limits. Root access, system control or needs beyond those limits: consider a VPS. For WordPress and other managed PHP services, see Sites. If you cannot tell where the frontend ends and backend begins, tell us the framework and services it uses, without sending secrets.

Publishing makes a website reachable; it does not guarantee Google will index it, rank it or that an AI will recommend it. First check that the site works and its public content answers visitors’ questions.