From Glitch Remix to Template‑Repos: Hosting Prototypes After the 2025 Shutdown

The problem: relying on Glitch for live demos

Until 2025, Glitch let you click “Remix” on any public project, edit a full‑stack Node.js app in the browser, and see it redeploy instantly. That workflow removed local setup, CI/CD, and secret‑management friction for teaching, workshops, and quick prototypes. When Glitch announced the end of app hosting and user profiles, any guide that still tells readers to deploy live on Glitch becomes misleading.

Why the remix model still matters

The core value wasn’t the Glitch domain; it was the ability to:

1. Clone a working starter with one click.
2. Edit code and see immediate results.
3. Share a runnable example without asking others to install dependencies locally.

Those benefits can be reproduced today by treating the remix pattern as a template repository plus a one‑click deploy button.

Worked example: Express app with a .env secret

Below is a minimal Express server that reads an API token from .env and returns it via a route.

// package.json
{
  "name": "glitch‑style‑starter",
  "version": "1.0.0",
  "main": "server.js",
  "license": "MIT",
  "dependencies": {
    "express": "^4.18.2",
    "dotenv": "^16.4.5"
  }
}

// server.js
require('dotenv').config();
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/api/token', (req, res) => {
  const token = process.env.API_TOKEN;
  if (!token) return res.status(500).json({error: 'token not configured'});
  res.json({token});
});

app.listen(PORT, () => console.log(`Listening on ${PORT}`));

On Glitch you would have added a .env file through the UI, clicked “Remix”, and the app would be live at https://project-name.glitch.me/api/token.

Alternative: GitHub template + deploy button

Create a public GitHub repository that contains the files above plus a README.md with a deploy button for your preferred host (Render, Fly.io, Vercel, etc.). The button encodes the required environment variable name so newcomers only need to fill in a value.

# README.md
# Express starter with .env

[![Deploy to Render](https://render.com/images/deploy-to-render-button.svg)](https://render.com/deploy?repo=https://github.com/yourname/express-starter)

## Local development
1. Copy .env.example to .env and set API_TOKEN=your‑value
2. Run:
   
npm install
npm start

3. Visit http://localhost:3000/api/token

When a visitor clicks the button, the host provisions a service, injects the API_TOKEN config var, and starts the Node.js process. The resulting URL works exactly like the former Glitch link.

Trade‑offs and limits

• Sleeping/free‑tier limits: Render’s free web service sleeps after 15 min of inactivity, similar to Glitch’s historic sleep. This is fine for demos but not for production traffic.
• Environment‑variable handling: Each host expects vars in its dashboard or via a render.yaml/fly.toml. You must document the exact variable name (API_TOKEN) for users.
• No built‑in editor: Unlike Glitch’s in‑browser IDE, users edit locally or via GitHub’s web editor. The trade‑off is a slightly higher setup barrier but full Git workflow.

Next steps

To verify the pattern works:

1. Fork the template repo.
2. Add your own API_TOKEN value in the host’s dashboard.
3. Trigger a deploy (via the button or manual push).
4. Run curl https://your-service.onrender.com/api/token and confirm you receive a JSON token.

If the endpoint returns the token, the remix‑style workflow is successfully replicated without depending on Glitch’s hosting.