Interstellar: a self-hosted web proxy that refuses to be a static site

The proxy needs a server, and the README says so bluntly

The first deployment instruction is a prohibition, not a command: you cannot deploy to static web hosts, including Netlify, Cloudflare Pages, and GitHub Pages. Everything else in the deployment section follows from that. A web proxy rewrites every URL it serves, so it cannot hand a browser a directory of HTML files and call it done. There has to be a process in the middle.

The package manifest confirms it. The start script is `node src/server.js`, and the dependency list is Express 4, cookie-parser, cors, dotenv, mime, node-fetch, chalk, plus express-basic-auth and express-rate-limit. That is a conventional Express application with a job to do, not a static build.

There is a Dockerfile at the root of the repository for anyone who wants the container path, and it is worth reading because it tells you what the maintainers consider the minimal production setup:

FROM node:bookworm-slim
ENV NODE_ENV=production

WORKDIR /app

COPY ["package.json", "./"]

RUN npm install

COPY . .

CMD [ "node", "src/server.js" ]

It copies the manifest first and installs before copying the source, which is a sensible caching pattern, then starts the same server entry point the npm script uses. Note it installs with npm while the project declares pnpm as its package manager, and the repository carries both a package-lock.json and a pnpm-lock.yaml.

The manual deployment path is two commands followed by a start command, and the README supports three package managers:

git clone https://github.com/UseInterstellar/Interstellar
cd Interstellar

Then `bun i` and `bun start`, or `pnpm i` and `pnpm start`, or `npm i` and `npm run start`.

Two licenses, and they are not the same obligation

Here is a discrepancy you need to resolve yourself, because the two sources disagree on something that changes what you are allowed to do.

GitHub reports the license as AGPL-3.0. The package manifest at the root of the repository declares `GPL-3.0-or-later`. Those are different licenses. AGPL is the GNU Affero General Public License, which adds a requirement that users interacting with the software over a network be offered its source. GPL-3.0-or-later has no such network clause.

For a project whose entire purpose is to be hosted and reached by other people over the network, that difference is not academic. If you run an Interstellar instance for a school or a group and the AGPL reading is the correct one, you are in a different legal position than the manifest suggests.

The thing to check is the LICENSE file at the root of the tree. Whichever license text is actually in that file is the license, and the two metadata fields are secondary. Read the file rather than trusting either.

A LICENSE file is present, along with SECURITY.md, CONTRIBUTING.md, a CHANGELOG.md, app.json, render.yaml and vercel.json, so the repository has a fairly complete set of operational files for a project of this kind.

The other metadata oddity worth noting is the scale of the fork count. GitHub reports 2,158 stars and 24,848 forks, which is an unusual ratio, and the README explains part of it by linking one-click deploy buttons for Heroku and Koyeb. Every person who clicked a deploy button created a fork, so the fork number is a deployment counter as much as a contributor signal.

Version 6 moved to Scramjet as the default and started obfuscating

The v6 release, dated 2026-09-19, is the substantive one and its notes are unusually informative about direction. On the proxy side it updated Scramjet and made it the default proxy, updated Ultraviolet to the latest version, and removed Dynamic proxy as outdated. The manifest backs this up: both @mercuryworkshop/scramjet and @titaniumnetwork-dev/ultraviolet are direct dependencies, alongside bare-mux, epoxy-transport, libcurl-transport and wisp-js from the same Mercury Workshop ecosystem.

On the server side it moved server code into /src/ and split it into modules, added rate limiting, and added hard caching for games.js. The rate limiting shows up in the manifest as express-rate-limit.

On the build side the notes are the part worth reading twice: it added a build pipeline that obfuscates the entire application, minified CSS during builds, obfuscated the Google Analytics script, and loaded particles locally. The manifest confirms the tooling, with javascript-obfuscator and terser in devDependencies and a build script of `node src/build.js`. Terser for minification, javascript-obfuscator for the obfuscation pass.

There are also fixes with real user impact. It added proper _top link interception in tabs to preserve normal site functionality, obfuscated the address bar in tabs, properly sanitized URLs, prevented service worker errors for new users, and made themes apply immediately on page load to fix a flashing bug.

The dynamic version and updated date in Settings is a small feature that tells you something about the project's priorities: this is software that people run as one instance and want to trust, and knowing you are on current code matters when your main interface is a browser window pointed at a third party site.

Cloaking is the feature, and it is also the ethical question

The README's feature list leads with two cloaking features, About:Blank Cloaking and Tab Cloaking, and v6's notes add obfuscating the address bar in tabs and intercepting _top links so normal site functionality is preserved.

What this does is make the proxied page present as a blank tab or as an untitled tab rather than as the site you are actually on. Tab cloaking obscures the address bar; about:blank cloaking is the heavier version where the tab appears to be a blank page. Interception of _top targets is the detail that makes it work: it rewrites links that would break out of the frame into in-frame navigation, so a site cannot navigate the tab away from the proxy.

Combined with the Now.gg Support and Gefence NOW Support entries in the feature list, the intended use is clear. This is aimed at students on school networks that block game and streaming sites, and the repository's topics include school, unblocked, unblocked-games and unblocker alongside proxies and web-proxy. The README's opening line claims it has served over 15 million users since 2022, which is a claim the project makes about itself rather than something independently verifiable.

Whether cloaking is appropriate is a question each deployment answers for itself, and it depends on whether you have the authority to bypass the network you are on. Where the project is straightforward is that it is not hiding this: the features are listed at the top, and there is a Discord community linked from the README for support.

The other features are more conventional: a built-in tab system, inspect element, various themes, optional password protection, a collection of apps and games, and what the notes describe as fast speeds.

Deployment reality, including the parts the project does not want you to skip

Beyond the local instructions there are hosted paths and the README is refreshingly specific about their failure modes.

GitHub Codespaces is documented as a working option, and it comes with a warning that matters more than it first appears. You have to click Make public on the port, or the proxy will not function properly, and the note repeats that if you get a Range Error you should go back and check that you clicked it. That is a real property of how Codespaces handles ports: the proxy needs a reachable endpoint, so port visibility is part of the setup, not an afterthought. The alternative when there is no popup is documented too, prepending a PORT value such as `PORT=6969 pnpm start` and then setting port visibility to Public in the ports tab.

Optional password protection is a config flag rather than a command-line flag. You set `challenge` to true in config.js and then pass config=true when starting, with forms given for pnpm, Bun and npm. Note that config.js sits in the repository root as a checked-in file, so a deployment that enables this needs its own secret handling rather than relying on the default file.

There is an Ad-Free deployment branch, cloned with `git clone --branch Ad-Free`, which is the clearest signal about how this project is funded. The README says plainly that as of now they need support in making it ad-free, and asks people to consider keeping ads so Interstellar can run freely or to contribute as a supporter. The 5.2.3 release notes include a pull request adding cloaking for sites other than NASA, which is a good illustration of the feature's granularity.

Replit deployment is documented as gone, with the reason given: as of January 1st, 2024, Replit is no longer free, and the suggestion is GitHub Codespaces instead. Render deployment is offered but the README routes people to Discord for the details.

Maintenance, tooling choices, and where to start

The repository is not archived and the last push was on 2026-09-28, nine days after the v6 release. The commit history around v5.3.0 shows dependabot bumping prettier and @biomejs/biome, an ImgBot optimizing images, and a large bulk pull request from one contributor, which is the shape of a project maintained by a small number of people plus automation.

Tooling choices are worth noting because they are not the defaults most people expect. Formatting and linting run through Biome rather than ESLint and Prettier, with a precommit script that formats then checks, enforced by husky through the prepare script. The package manager is pinned to a specific pnpm version with an integrity hash. There are pnpm overrides forcing newer versions of qs and uuid, which is dependency hygiene in response to advisories, and a patchedDependencies entry for bare-mux pointing at a patch file in the patches directory, which is the kind of thing you find in a project that has hit a real bug in a dependency and worked around it in-tree.

Node 16 or newer is the declared engine floor and npm 7 or newer for the package manager side.

If you want to see what this is before reading the source, the tree is a reasonable map: src/ for application and server code, static/ for assets, config.js for configuration, biome.json for tooling, Dockerfile, app.json for a platform config, render.yaml for Render and vercel.json for Vercel. The README points to the examples of deployed instances through its Discord rather than hosting a list, so the fastest evaluation is to run the Dockerfile, open it, and load a page through it.

Editorial conclusion

Interstellar is worth understanding as an architecture rather than adopting as infrastructure. The whole design follows from one decision: because a web proxy has to rewrite URLs, it cannot be a pile of static files on a CDN, so there is an Express server, a URL rewriting layer in the browser, and a deployment section that explicitly rules out Netlify, Cloudflare Pages and GitHub Pages. Version 6 tightened that server side, adding rate limiting, moving server code into modules under src, and obfuscating both the application bundle and the analytics script at build time. Two things to settle before you run it yourself: the license, because GitHub reports AGPL-3.0 while the package manifest declares GPL-3.0-or-later and those are different obligations for anyone offering it as a service, and the ad question, which the README raises directly when it says keeping ads is what lets the project run freely. Read the LICENSE file at the root rather than either metadata field, and start from the Dockerfile in the repository if you would rather not read the deployment guide.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. UseInterstellar/Interstellar on GitHub