# PokéRogue: running the browser Pokémon roguelite from source

> PokéRogue is a TypeScript Pokémon fangame built around roguelite runs, stacking items and endless biomes. This covers what the repository actually gives you, how to run it locally, and who should stay on pokerogue.net instead.

**pagefaultgames/pokerogue** — A browser based Pokémon fangame heavily inspired by the roguelite genre.

- Repository: https://github.com/pagefaultgames/pokerogue
- Website: https://pokerogue.net
- Stars: 5,863 · Forks: 2,391
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/pagefaultgames-pokerogue

## What PokéRogue is, and who the repository is actually for

PokéRogue is a browser based Pokémon fangame, described in its README as "heavily inspired by the roguelite genre". A run is endless: you battle, collect stacking items, move through biomes, and meet trainers and bosses along the way. The gameplay loop is the product; the repository is the source that produces it.

That distinction matters more than it usually does. The README's only pointer for getting the game running is a link to CONTRIBUTING.md, which it says "includes instructions on how to set up the game locally". There is no player-facing install section, no desktop download, no app store link. The homepage field points to pokerogue.net, which is where the README expects players to go.

So the audience for this repository is narrow and specific: people who want to read, build, patch or self-host the game. If you want to play, the repository is the long way around. If you want to understand how a Pokémon battle engine is structured in TypeScript, or you want to run your own instance with login bypassed, it is the only way in.

## The Vite and pnpm architecture behind a PokéRogue run

The stack is a Vite application written in TypeScript, with pnpm as the package manager. The repository carries pnpm-lock.yaml and pnpm-workspace.yaml at the top level, and the Dockerfile pins the toolchain explicitly: it enables corepack and prepares pnpm@10.34.5, with Node 24.9 on Alpine as the base image. The package name is pokemon-rogue-battle and the version in package.json is 1.12.1.0, which sits ahead of the most recent tagged hotfix, v1.12.0.11.

Scripts are split by environment rather than by task. start:prod, start:beta and start:dev each run Vite with a different mode, and build, build:beta, build:dev and build:app mirror that split on the build side. There is a separate start:podman script that runs Vite in development mode bound to 0.0.0.0 on the port taken from $PORT, which is what the container uses.

Mode selection is not cosmetic. The repository ships .env, .env.app, .env.beta, .env.development, .env.production and .env.test at the top level, so each mode resolves a different set of variables. The Dockerfile sets VITE_BYPASS_LOGIN=1 and VITE_BYPASS_TUTORIAL=0 in the image environment, which is how a containerised instance skips the account flow. If you build for a mode whose env file you have not reviewed, you are shipping whatever that file contains.

Quality tooling is unusually complete for a fangame. Biome handles linting and formatting (biome.jsonc, with biome, biome:staged, biome:all and biome:ci scripts), Vitest handles tests (test, test:cov, test:watch, test:silent, test:merge-reports), and there are four separate typecheck targets: typecheck, typecheck:main, typecheck:github and typecheck:js. Dependency boundaries are declared in .dependency-cruiser.cjs, and lefthook.yml wires git hooks. The README links both a test coverage badge and a docs coverage badge, with generated API documentation published from the repository.

## Installing PokéRogue locally with pnpm

The README does not reproduce setup steps; it defers to CONTRIBUTING.md for local installation. The package.json scripts are the reliable starting point, and the repository pins the runtime in .nvmrc, so match that Node version before installing. With pnpm available, the development server starts from the mode-specific script.

```bash
pnpm install
pnpm run start:dev
```

Vite serves the game and prints the local URL in the terminal. The dev mode reads .env.development, so anything you change there takes effect on the next restart. For a production-shaped build instead:

```bash
pnpm run build
pnpm run preview
```

preview serves the built output so you can check the production bundle without deploying it. Note that build and build:beta are separate targets; a beta build reads .env.beta and is the one that matches the branch this repository defaults to.

If you would rather not manage Node and pnpm yourself, the Dockerfile is the supported container path. It creates a non-root appuser, installs dependencies with a frozen lockfile, sets PORT=8000, exposes that port, and starts the app with pnpm run start:podman. Because the image sets VITE_BYPASS_LOGIN=1, a container started from it will not present the login flow. The Dockerfile's own comment describes the command as starting "the app in development mode", so treat the image as a development environment rather than a hardened deployment.

## Where PokéRogue stops being the right tool

The most common mismatch is expecting a game download. This repository does not produce a mobile app, a desktop executable, or a console ROM. It produces a web build. People searching for a PokéRogue app for iOS, a PokéRogue ROM, or a PokeRogue GBA file are looking for something this repository does not contain, and no amount of building will change that.

Offline play is a second mismatch, and a subtler one. A self-hosted instance removes the dependency on pokerogue.net, but it does not remove the account and save layer that the login flow implies. VITE_BYPASS_LOGIN=1 lets you skip the login screen in the container image; the README and the Dockerfile say nothing about what happens to save data in that configuration. If your goal is a single-player game that runs with no server at all, verify the save path before you invest in a setup.

The third constraint is licensing, and it is not uniform across the tree. The README states that source code is AGPL-3.0-only unless noted, documentation is CC-BY-NC-SA-4.0, and auto-generated or low-originality files are CC0-1.0. Assets are the sharp edge: the README warns that files in assets/ which are not explicitly licensed via REUSE.toml files "should be considered to have no licensing / copyright information". A fork that redistributes the game is therefore redistributing material whose status the project itself declines to assert. That is a reason to keep a fork private or to replace assets, not a reason to assume the whole tree is uniformly covered. The README says the repository seeks REUSE compliance and points to reuse spdx for the per-file answer.

Finally, the beta branch and hotfix cadence are a trade-off. Releases like v1.12.0.11, v1.12.0.10 and v1.12.0.9 are labelled hotfixes and land weeks apart, while package.json already reads 1.12.1.0. If you pin to a tag, expect to move again soon.

## PokéRogue against a general web game engine

The obvious alternative for someone building a browser roguelite is a general engine such as Phaser or PixiJS, or a framework like React with a canvas layer. The difference is not quality, it is domain coverage. An engine gives you a render loop, sprite batching, input handling and a scene graph, and leaves the battle rules, the species data, the item stacking and the AI to you. PokéRogue inverts that: the engine-level concerns are comparatively thin, and the bulk of the code is game logic, data and UI for a specific genre.

That makes PokéRogue a poor starting point for an unrelated game and a strong one for a Pokémon-like. The item stacking, biome traversal, trainer and boss encounters, and the endless run structure are already modelled. The cost is that you inherit the project's data shapes and its AGPL-3.0-only source licence, which is a copyleft obligation that a permissively licensed engine does not impose. If you want to build a commercial closed-source roguelite, an engine is the cleaner choice. If you want to build a Pokémon fangame, reimplementing this much logic from scratch is the harder path.

For players, the alternative to self-hosting is simply pokerogue.net, which the README treats as the place to play. Running the repository yourself buys you control over the build and the environment variables, not a different game.

## Maintenance, releases and what a fork inherits

The repository is not archived, and the last push was on 2026-09-22. Recent tagged releases are hotfixes: v1.12.0.11 on 2026-08-23, v1.12.0.10 on 2026-07-25 and v1.12.0.9 on 2026-07-17. The default branch is beta, which tells you where development attention sits relative to the tags.

The upgrade cost for a fork is mostly mechanical but not free. Dependencies are locked through pnpm-lock.yaml, so a rebase means resolving lockfile conflicts and re-running pnpm install. Type errors surface through tsc via the four typecheck scripts, lint regressions through Biome, and dependency-boundary violations through .dependency-cruiser.cjs. The test suite runs under Vitest, and test:merge-reports exists specifically for combining sharded CI results, which suggests the suite is large enough to shard. A fork that skips these checks will drift from upstream quickly.

On licensing, the practical points are these. Source is AGPL-3.0-only, so a modified version offered over a network carries source-availability obligations. Documentation is CC-BY-NC-SA-4.0, which includes the non-commercial term. Assets are the unresolved part, and the README says so explicitly. The repository also carries a CREDITS.md and asks that asset producers not listed there reach out via GitHub or Discord. Anyone forking should read REUSE.toml files rather than assume, and should not treat this article as legal advice.

## Conclusion

Adopt it if you want to read or modify a large TypeScript game, or you need a self-hosted build behind VITE_BYPASS_LOGIN. Do not adopt it expecting a packaged mobile app or an offline single-file download: the repository ships a Vite web build and a Dockerfile that starts a development server, and the README points players at pokerogue.net. Before committing, check CONTRIBUTING.md for the current local setup steps, confirm the AGPL-3.0-only scope with reuse spdx, and decide whether you can live with a beta branch that receives hotfix releases such as v1.12.0.11.

## FAQ

### How does PokéRogue work?

It is a browser based Pokémon fangame built around roguelite runs: you battle endlessly, gather stacking items, and move through different biomes while fighting trainers and bosses. The README describes it as heavily inspired by the roguelite genre.

### Is the PokéRogue app safe?

The repository does not ship a mobile app, so there is no official PokéRogue app to assess here. The README points players at pokerogue.net, and the only local setup it references is CONTRIBUTING.md for running the game yourself.

### How do I install PokéRogue?

The README defers local setup to CONTRIBUTING.md. From the package scripts, pnpm install followed by pnpm run start:dev serves the game through Vite, and the repository also includes a Dockerfile that installs dependencies and starts the app on port 8000.

### What is PokéRogue based on?

It is a Pokémon fangame written in TypeScript, built with Vite and managed with pnpm, and the README says it is heavily inspired by the roguelite genre. The source is licensed AGPL-3.0-only unless a file says otherwise.

## Sources

- [License: AGPL-3.0](https://github.com/pagefaultgames/pokerogue/blob/beta/LICENSE)
- [pagefaultgames/pokerogue on GitHub](https://github.com/pagefaultgames/pokerogue)
- [Project website](https://pokerogue.net)
- [README](https://github.com/pagefaultgames/pokerogue/blob/beta/README.md)
- [Releases](https://github.com/pagefaultgames/pokerogue/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pagefaultgames-pokerogue