Giving your project an address of its own

With the files, configuration and dependencies in place, the project may run happily on your laptop. Earlier we saw why its localhost address belongs to that machine. Giving other people an address they can use also means deciding what to run there.

npm run dev typically starts a development server, according to the script in package.json. It watches files, rebuilds on changes and helps you see errors. Visitors need the version you intend to serve, rather than your editing environment. Getting from one to the other involves a build, a place to run it and a public address.

What a build makes

npm run build runs whatever command package.json lists under build. What comes out depends on what kind of app you have.

A static app has no code that must run on a server. Picture the notebook app built with Vite, keeping its notes in browser storage. Its build produces a folder, usually dist, holding index.html, JavaScript and CSS. That folder is the whole site. Any file host can serve it, and you can serve it yourself the way you served the hello page.

npm run build
python3 -m http.server 8000 --directory dist

A server app has code that runs per request: API routes, pages rendered on the server, anything that reads a secret while answering. Its build output needs a compatible runtime. It prepares files that a server process then runs, and that process has to keep running. In Next.js, next build is followed by next start. The production command is whichever one your framework documents as supported for production. The dev server is not one of them.

Knowing which kind you have decides everything after this point. A static host still runs software that serves the files; you do not manage a custom application runtime there. Server output needs a supported runtime, whether a long-lived process or managed functions started on demand.

The first real deploy

Hosting platforms automate the same steps you would do by hand. You connect the repository, and on each push the platform installs dependencies, preferably with npm ci, runs the build, and then either uploads the static folder or starts your server process with the start command.

You tell it the build command, the output folder or the start command, the Node version, and the production environment variables. When a deploy fails, the build log is an error message like any other. Read the first line, find the first frame in your own code, and remember the usual suspects: a path whose capitalisation only worked on your laptop, an environment variable that exists in your .env and not on the platform, a lockfile that does not match package.json.

Then close the laptop, switch your phone to mobile data and open the address the platform gave you. This is the moment the code starts living without you.

Domain and DNS

The platform gives you an address like notebook-a1b2.example-host.app. To use your own name, you buy a domain from a registrar and then create DNS records, which tell the world where the name points. An A record maps a name to an IPv4 address, an AAAA record to an IPv6 address, and a CNAME points a name at another name. Your host will tell you which records to create.

Changes take a while to be seen everywhere, because resolvers cache each answer for the record's TTL, its time to live. You can ask what a name resolves to right now:

dig notebook.example.com
nslookup notebook.example.com

The address records in this example resolve names; DNS has other record types too. It says nothing about whether the connection is encrypted, or whether the machine at that address is really yours.

HTTPS

HTTPS adds two things on top: an encrypted connection, and a certificate that proves the server is entitled to answer for that name. A certificate authority issues the certificate after the server shows it controls the domain, and hosting platforms usually do this automatically, often through Let's Encrypt, once your DNS points at them. That is why the padlock can lag a few minutes behind the name starting to work.

If the certificate does not match the name, the browser shows a warning instead of your page. If it does match, the padlock means the connection to that name is private and the name is the one on the certificate. It does not mean the site behind it is safe or honest. It protects the connection against eavesdropping and tampering in transit; the endpoints still receive the content.

Your production build

Run your project's production build on your own machine with the supported production command, and click through every page. The dev server hides things, and this is the cheapest place to find them. Then write one sentence: my app is static, or my app needs a running server, and here is where that server will run.