Deploying a Node.js App to Glitch with the CLI: Env Vars and Live Reload

You have a small Node.js app running locally and you want it live on a public URL without setting up a server. Glitch hosts the app, restarts it on every file change, and injects environment variables at runtime. This guide walks through deploying with the Glitch CLI, configuring secrets safely, and verifying that live reload works. Note that Glitch's hosting features have changed over time, so treat the exact UI labels and CLI behavior below as a baseline and confirm against the current Glitch documentation before relying on them in production.

What you need before pushing

• A Glitch account and a project created from the web UI. Note the project ID or project name from the project URL.
• Node.js and npm installed locally (any recent LTS release is fine).
• The Glitch CLI installed globally: run npm install -g glitch in your local terminal, then authenticate with glitch login and follow the prompt.
• An app that listens on the port Glitch provides. Glitch sets the PORT environment variable; your server must use it:

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

app.get('/', (req, res) => {
  res.send(`Hello from Glitch. Mode: ${process.env.APP_MODE || 'unset'}`);
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on ${port}`));

Hard-coding port 3000 works locally but can break on Glitch if the platform assigns a different port, so always prefer process.env.PORT.

Prepare dependencies so Glitch installs the same tree

Glitch installs dependencies from your package.json (and lockfile, if present) after each push. To keep the hosted environment identical to your local one:

1. In your project directory, run npm install so package-lock.json is up to date.
2. Confirm your package.json has a start script, e.g. "start": "node server.js". Glitch uses this to launch the app.
3. Add a .gitignore-style exclusion for node_modules — pushing your local node_modules wastes bandwidth and can ship platform-specific binaries that fail on Glitch's Linux containers.

Push the project with the Glitch CLI

From your local project root, run the push command with your project identifier:

glitch push your-project-name

Replace your-project-name with the actual project name from your Glitch dashboard. The CLI uploads your working tree and triggers a dependency install and restart on the Glitch side. If the push fails with an authentication error, re-run glitch login; if it fails partway through, check your network and retry — a partial push does not leave the running app in a half-updated state because Glitch restarts only after the upload completes.

Set environment variables in Secrets, not in code

Glitch injects variables from the project's Secrets (historically the .env file in the editor) into process.env at runtime. In the web editor, open the Secrets panel and add key/value pairs such as:

APP_MODE=production
API_KEY=replace-with-real-value

Two cautions matter here:

• Anyone with edit access to the project can see these values. Do not put production-grade credentials in a project you share for collaboration.
• Never commit real secrets to the files you push. Keep a .env.example with placeholder names so collaborators know what to configure.

Verify the deployment

Do not assume the push worked — check each layer:

1. HTTP check: open the project's public URL (shown in the Glitch editor under Share/Preview). You should see the response from your route, including the APP_MODE value if you set it.
2. Runtime check: open the project's console (Logs > Console in the editor) and run node -v and npm -v. Compare with your local versions; a major mismatch can explain dependency install failures.
3. Env var check: in the same console, run node -e "console.log(process.env.APP_MODE)". It should print the value from Secrets. If it prints undefined, re-check the key name for typos and restart the app.

Confirm live reload actually restarts the app

Glitch watches project files and restarts the app when they change. To verify the loop end to end:

1. Edit the response string in server.js in the web editor (or push a small change from the CLI).
2. Watch the Logs panel for a restart message.
3. Reload the public URL and confirm the new string appears.

If you push via CLI and the change does not appear, the most common causes are a failed dependency install (check Logs for npm errors) or the app crashing on startup (check for an uncaught exception in the log output). Fix locally, re-run npm install if dependencies changed, and push again.

Limits to plan around

• The free tier historically caps memory around 512 MB and idles inactive projects. Memory-heavy builds or large dependency trees can trigger restarts; keep the dependency list lean.
• There is no traditional rollback button for a bad push. Your practical recovery path is Git: keep your local repo committed before each glitch push, so git revert plus another push restores a working state.
• Because Glitch restarts on file changes, avoid writing to the project directory at runtime (e.g., log files or uploads) — writes can trigger restart loops. Use an external store for persistent data.

With the push verified, secrets in place, and live reload confirmed, you have a tight iterate-and-check loop: edit locally, glitch push, reload the URL.