Open-source project
foundryvtt/pf2e avatar
foundryvtt/pf2e

pf2e: a community game system for Pathfinder Second Edition

A community contributed game system for Pathfinder Second Edition.

649 stars518 forksTypeScriptApache-2.0

At a glance

What is it?
The pf2e system is a volunteer maintained implementation of the Pathfinder Second Edition rules for Foundry Virtual Tabletop, built in TypeScript and Svelte, and it now carries a second Starfinder Second Edition system alongside it. The code is Apache 2.0 licensed, the game content sits under the Open Game License, and the project states plainly that the work is not finished.
Who is it for?
Adopt pf2e if you run Foundry Virtual Tabletop and want a current Pathfinder Second Edition rules implementation maintained by a volunteer team, with the standard Foundry module system layout and the option of a Starfinder Second Edition system in the same repository.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A volunteer rules implementation with a permission grant behind it

pf2e is a system implementation of Pathfinder Second Edition for Foundry VTT, and the first thing the readme deals with is legal rather than technical.

The system uses trademarks and copyrights owned by Paizo, used with permission granted as part of the partnership agreement between Foundry Gaming and Paizo. It is created and maintained by the PF2E for Foundry VTT volunteer development team, and published for free with the endorsement of Foundry Gaming.

That structure tells you something about the project's durability. The rules content cannot simply be forked into a new project, because the permission comes from a specific agreement. The readme says that if you want to undertake a similar project, much of what this system includes is covered under Paizo's Community Use Policy, which is a pointer to a licence that lets other projects reuse the same content under conditions set by Paizo rather than by this team.

So there is a boundary here between the code and the content, and it is worth understanding before you look at the repository. The code is open. The rules and the art are licensed separately, and the art licensing information lives in the static/licenses directory with release builds including it under licenses.

The platform itself has its own terms, the Limited License Agreement for module development dated 09/02/2020, and this game system for Foundry is licensed under it.

Three licences, and which one covers what

The readme splits licensing into three groups, and the split is the practical part of understanding the repository.

The first is project licensing. All HTML, CSS and Javascript in the project is licensed under the Apache License v2, which is also what the package manifest declares. That is the permissive licence most developers will actually interact with, and it is the one that governs the TypeScript, the Svelte components and the build scripts.

The second is content usage and licensing. Any Pathfinder Second Edition information used is with permission granted by the agreement between Paizo and Foundry Gaming. Game system information and mechanics are licensed under the Open Game License, version 1.0a. That is the licence that matters if you are writing content of your own for this system, because it is the licence the mechanics themselves carry.

The third is the platform licence, the Limited License Agreement for module development, which is what allows the system to be distributed as a Foundry module at all.

The practical guidance is that any organisation using this should have someone read the Open Game License and the Foundry module agreement rather than assume the Apache 2.0 on the code covers the game. The distinction between code and content is exactly the kind of thing that is easy to miss and awkward to unpick later, and the readme is unusually clear in setting it out.

The code licence is also the most permissive of the three in the sense that a forking engineer has the least friction, which is a contrast with the content, where Paizo's policy sets the terms.

One repository, two game systems, and a dev branch that is not main

The repository layout shows something that a casual glance would miss: this is not a single game system project any more.

At the root there are two sets of manifest files. system.pf2e.json and module.pf2e-anachronism.json describe the Pathfinder Second Edition system and its anachronism module, and system.sf2e.json with module.sf2e-anachronism.json describe the Starfinder Second Edition equivalents. The release tags confirm it, with pf2e-8.6.1 and sf2e-1.6.1 both published on 2026-10-12, and a separate sf2e-anachronism-2.4.0 on 2026-10-08. There is even a separate changelog file, CHANGELOG (SF2E).md, alongside the main CHANGELOG.md.

The package name is foundry-pf2e and the version in the manifest is 8.6.1, so the root manifest still tracks the Pathfinder line, with the Starfinder build produced from the same build tooling.

The default branch is v14-dev, which is a development branch for the next major version rather than a stable one. That is worth noting when you are tracking the repository, because the branch name signals that the current release line and the development line differ, and a contributor is expected to work against the development branch.

The system is distributed through the Foundry Virtual Tabletop marketplace, with the homepage being the package page on foundryvtt.com/packages/pf2e, so a user installs it from the marketplace rather than building it.

The build pipeline is a set of pack and system builders

The build system is a set of TypeScript scripts driven by pnpm, and the manifest gives a good picture of how a Foundry system is put together.

The build entry point runs the pack and system builds, and the individual scripts are separate:

json
        "build": "pnpm run \"/build:(?:packs|system)$/\"",
        "build:system": "tsx ./build/build-system.ts",
        "build:packs": "tsx ./build/build-packs.ts",
        "build:packs:json": "tsx ./build/build-packs.ts --json",
        "build:conditions": "tsx ./build/conditions.ts",

The packs and the system are separate artefacts, which is the standard Foundry structure: the system holds the rules and the code, and the packs hold the content that gets imported into a world. The build:packs:json variant produces a JSON output of the packs, and build:conditions builds the conditional content separately.

There is a dedicated anachronism build, a build:anachronism script pointing at ./build/anachronism/index.ts, matching the anachronism module manifests at the root, so a variant system with different rules content is built from the same source tree.

For development there is a hot script for hot module replacement, a link script that links the built system into a local Foundry installation, and an extractPacks script that pulls packs back out. The migrate script runs a data migration, which is the mechanism for keeping saved worlds working across rule changes, and that script is the one to read first if you are upgrading an existing world.

The build directory at the root holds all of these scripts, and the packs directory holds the content sources, with the src directory holding the application code.

Svelte, TypeScript, and the test and lint setup around them

The application stack is TypeScript with Svelte components, built with Vite and tested with Vitest, and the configuration files at the repository root show it plainly. There is a vite.config.ts, a vitest.config.ts, a tsconfig.json, a typedoc.json for API documentation, an eslint.config.js and a.prettierrc.json.

The Svelte packages in the development dependencies are the Svelte Vite plugin, and the Prettier lint task is scoped to styles and svelte files, which tells you that the interface layer is Svelte while the logic layer is TypeScript. The pixi packages in the manifest, basis, graphics-smooth and particle-emitter, are for the 2D rendering that a virtual tabletop needs on its map layer.

The lint and test setup is stricter than a typical hobby project. The lint script runs eslint with a cache and then the Prettier check, and the test script runs vitest, with a pretest hook that runs lint first, so a test run fails on style before it fails on behaviour. There is a lint:fix script that applies the fixes.

Two details in the repository are worth a note. The roll-grammar.peggy file at the root is a grammar for a parsing tool, which is how a rules system with a custom expression language is usually handled. And the engines field requires Node 24.14.0 or later, with pnpm 10.34.5 as the package manager, so a contributor's toolchain has to be current.

The top level also has a tests directory of its own, alongside the build directory and the packs and src directories.

What the project says about its own completeness

The readme has a short section, and it is more candid than most, so it deserves to be quoted rather than paraphrased away. The note says that the functionality of this project is not complete and there is plenty of work remaining.

That is a volunteer project statement rather than a defect report, and it comes with the mechanism for influencing it. Suggestions and feedback go to the #pf2e channel on the Foundry Discord server, the project points at its CHANGELOG for patch notes and at CONTRIBUTING.md for the contribution process, and the whole thing is built by a volunteer development team rather than by a company with a roadmap.

There is also a practical benefit to the arrangement that is easy to overlook. Because the system is a Foundry module, it inherits the platform's own capabilities and its own version, and because the content is licensed rather than owned, a change to the underlying rules or to the platform does not require the system to be rewritten from scratch. The anachronism module pattern is a good example: a variant of the rules content built from the same source, which is only possible because the content is data rather than code.

The realistic picture for an adopter is a large, actively maintained community implementation with a stated list of remaining work, whose patch notes are the place to look for what changed in a given release, and whose licence structure means you should read three documents before you build anything on top of it.

Editorial conclusion

Adopt pf2e if you run Foundry Virtual Tabletop and want a current Pathfinder Second Edition rules implementation maintained by a volunteer team, with the standard Foundry module system layout and the option of a Starfinder Second Edition system in the same repository. Do not adopt it if you need a finished product with a support commitment, because the project states the functionality is not complete and that plenty of work remains, and do not redistribute the game content without reading the Open Game License terms. Before you commit, install the package from the Foundry marketplace, read the CHANGELOG for the current release, and check the Paizo Community Use Policy if you are planning to build on this system.

Frequently asked questions

What is the pf2e Foundry VTT system?

It is a system implementation of Pathfinder Second Edition for Foundry Virtual Tabletop, created and maintained by the PF2E for Foundry VTT volunteer development team and published for free with the endorsement of Foundry Gaming. The repository also contains a Starfinder Second Edition system and anachronism modules for both.

How is the pf2e system licensed?

Three licences apply. All HTML, CSS and Javascript in the project is under the Apache License v2, game system information and mechanics are under the Open Game License version 1.0a, and the module itself is under the Limited License Agreement for module development from Foundry.

How do I install the Pathfinder Second Edition system in Foundry?

Through the Foundry Virtual Tabletop marketplace, at the package page foundryvtt.com/packages/pf2e. The releases are published under names such as pf2e-8.6.1 and sf2e-1.6.1, and the changelog in the repository records the patch notes for each release.

Is the pf2e system finished?

No, and the project says so directly. The readme states that the functionality of this project is not complete and that there is plenty of work remaining, with suggestions and feedback taken through the #pf2e channel on the Foundry Discord server.

How is the pf2e system built from source?

With pnpm and TypeScript scripts under the build directory. The build target runs the pack and system builds, with separate scripts for the system, the packs, the JSON pack output, conditions and the anachronism variant, and a migrate script that runs data migrations so existing worlds keep working across rule changes.

Official sources

  1. foundryvtt/pf2e on GitHub
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/foundryvtt-pf2e.svg)](https://hysenlabs.com/projects/foundryvtt-pf2e)

Was this useful?