Where It Runs
Laptop, web hosting, and a VPS — what “deploy” has to include.
Learning objectives
- Separate a laptop demo from a production host
- List what “deploy” includes beyond uploading files
- Pick a starting host from the stack, including a one-process MVP with SQLite
Your laptop is a host with an audience of one
npm run dev starts a development server bound to your machine, often at http://localhost:3000. It reloads when files change, prints errors on purpose, and dies when you close the lid. Production is the opposite: a process that restarts if it crashes, a name on the public internet, HTTPS, and a database that is still there tomorrow.
Three places an app can live
| Place | Fits | Struggles with |
|---|---|---|
| Web hosting (PHP, cPanel, WordPress plans) | WordPress, Laravel, and other PHP apps that run per request. | A Node or Python process that must stay listening on a port. Some plans can do it. Many cannot. Ask before you build. |
| A VPS | Node, Python, Docker, and PHP. You (or your host) install the runtime and keep the process running. | You are responsible for updates, backups, and the firewall unless the plan is managed. |
| Your laptop | Building and showing one person. | Anyone else, any restart, any real domain. |
Where the MVP lives
The simple stack from the last chapter — single-page app, one process, studio.db — wants one small VPS, not a database cluster. The process serves the built SPA and the API on the same machine. The SQLite file sits on a disk that is still there after a reboot or a redeploy. A nightly copy of that file is the backup. Ordinary PHP web hosting can serve the SPA’s files, but only if something is also running the API; for the first version, one machine doing both is the setup you can explain.
A single-page app adds one host rule. Unknown paths such as /classes/thursday must return index.html, or a refresh becomes a 404. A multi-page PHP app does not need that rewrite. Each URL is a real request.
Deploy means five things, not one upload
- Code on the server, including a production build if the stack has one (
next build,npm run build). - Environment — the real
DATABASE_URL,APP_KEY, and site URL. Not the example file. - Process — the app starts on boot and restarts after a crash. PHP-FPM, systemd, or the platform’s process manager.
- Name and lock — a domain pointing at the server, and a certificate so the site is HTTPS. Book 1 and Book 2 cover DNS and certificates in depth.
- Data — an empty production database, migrations applied, and a backup that is not the same disk as the database. For the MVP, that database is
studio.dbon persistent disk, and the backup is a copy of the file.
A booking site for one studio does not need the server you would buy for ten thousand users. Put it on a base plan that can actually run the stack, watch what it uses (CPU, memory, database size), and upgrade that same server when the numbers say so. Guessing the size up front is how people pay for idle machines — or launch on a plan that cannot start Node at all.
Which host can start it?
Workshop Co.’s app is Next.js with Postgres. A friend offers three options: (a) a PHP web-hosting plan with no Node and no shell, (b) a small VPS with root access where Node and Postgres can be installed, (c) keep running npm run dev on the studio iMac. Which one can be production, and what is still missing after you pick it?
Answer
(b) is the one that can run this stack. (a) cannot start the Node process. (c) is a demo. After choosing the VPS you still need the production build, real environment variables, a process manager, a domain and HTTPS, Postgres running with backups, and the migrations applied. The VPS is the place those five things can exist. It is not itself the deploy.