Glitch's Instant Live Preview for Node.js: What Restarts, What Reloads

The problem: every save costs a context switch

Iterating on a Node.js app locally usually means three actions per change: stop the server, start it again, and reload the browser tab. None of those is hard on its own, but together they turn a two-second edit into a ten-second interruption, and the interruption is what breaks the train of thought.

The thesis: on Glitch, saving the file is the only trigger

Glitch's editor, terminal, and preview pane share a single filesystem inside one container. Because the editor watches that filesystem, a save is enough to restart the server process and refresh the preview. You do not configure a separate dev server, a watcher, or a browser extension.

What the file watcher actually restarts

When you save a file, the platform's file watcher signals the Node.js process to exit and start again from the project's start script. The preview pane is essentially a browser view pointed at the running server, so once the process is back up it serves the new HTML, CSS, and JavaScript. The practical consequence: a syntax error in a saved file takes the preview down until you fix it, because the restart fails. The terminal log is where you find out why.

Terminal commands run against the same files

The terminal is not a separate sandbox. Running npm install express there writes into the same node_modules the server process reads, and the resulting change to package.json or the lockfile can itself trigger a restart. That is convenient, but it also means a long install can restart the server mid-command.

Worked example: a route that changes on save

Assume an Express 4.x project whose start script runs node server.js. Create or replace server.js:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Express at ' + new Date().toISOString());
});

app.get('/key', (req, res) => {
  res.send('Key value: ' + (process.env.MY_KEY || 'not set'));
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log('listening on ' + port));

Then, in the terminal pane:

npm install express

Add a line to the project's .env file:

MY_KEY=test123

Save, then open /key in the preview. If the route returns the value, the environment variable reached the process. Now edit the string in the first route, save again, and the preview should show the new text without a manual reload.

How to check the result

• Watch the terminal pane immediately after a save: a successful restart prints the process output again, and a failed one prints a stack trace.
• Open the browser's network panel and reload the preview manually to confirm the response body matches the code you just saved. This is the quickest way to tell a stale preview from a broken route.
• If /key returns "not set", either the variable is missing from .env or the process did not restart after you added it.
• If the preview shows a connection error, check the logged port against the one the platform expects your server to bind to.

Trade-offs worth planning around

Three limits matter more than the rest. All three are worth confirming against Glitch's current documentation, because platform limits change and this draft has not been verified against the live product.

• Idle sleep. Free projects are documented to sleep after a period of inactivity, so the first request afterwards pays a cold-start delay. That is fine for prototyping and awkward for a demo you cannot babysit.
• Storage. The project filesystem has a modest cap, and node_modules plus binary assets count against it. Large uploads can fail or be pruned.
• Secrets. .env values are hidden from the file tree but readable by anyone with project access, and they are not encrypted at rest. Treat them as development-only and keep production keys elsewhere.

None of these is a reason to avoid the live preview. They are reasons to decide early whether the project is a sketch or something that has to stay up.

What to do next

Use the save-triggered restart loop where feedback speed matters: route shapes, template markup, small data transformations. Before you share a URL, check the terminal for a clean start, confirm the storage figure in the project's resource view, and move any real credentials out of .env. If you need always-on behavior or assets beyond the storage cap, plan the move to conventional hosting once the prototype has done its job.