Know what you play.
Know what you run. Control what it can access.
See the source, review permissions, and verify the creator before you play. GamePKG builds your chosen packages locally and limits their access through an isolated runtime. GamePKG is a package format and player; creators host their own games, and you choose where to obtain them.
Download for Linux Download for WindowsVerify your download with the release checksums. Windows source builds use a matching Linux compiler inside WSL 2; playback opens in a separate game process and window. The library stays available. Follow the Windows setup guide.
Try the signed demo catalog: import it into your library, choose a game, approve its creator, then Build and Play. Some packages need player-provided ROM files; each manifest lists its requirements. Players need no signing key. A portable demo store is also available.
A game package you can inspect.
An opaque executable is difficult to review. When launched without a sandbox, it may inherit your account's access to files, network connections, and other programs. GamePKG brings source visibility, signed contents, restricted builds, and declared capabilities into one workflow.
Each .gamepkg carries Rust source, Slang shader source, assets, and a signed manifest. You can inspect its code and permissions before installing it. Source visibility makes review possible; it does not prove safety. Conventional signed binaries and separately sandboxed apps can also offer protections.
See what you run.
Review the source, creator fingerprint, permissions, and any user-provided ROM requirement.
Build for your machine.
Verify signed contents and compile directly for the current Linux CPU in a private, network-isolated work area. Wasm and web builds have separate controls.
Grant specific access.
The host exposes scoped assets, selected ROMs and files, saves, drawing, audio and permitted networking. Native Linux workers use OS isolation; separate Wasm builds use the sandboxed runtime.
Limits that belong in the format.
| Protection | What it controls |
|---|---|
| Signed packages and updates | Detect altered signed contents. Require the same creator key and game ID, plus a newer version, for updates. First installation still requires creator approval. |
| Bounded archive access | Reject traversal paths, duplicate entries, symlinks, and oversized archive contents. Read assets from the archive without extracting the whole game. |
| Restricted source profile | Checked Rust source modules, no guest Cargo dependencies, no build scripts or procedural macros, and Slang-only shader source. Every packaged Rust file is scanned. |
| Isolated compilation | Linux builds use bubblewrap, a private work area, no network, no user home access, and a 60-second deadline. Sandbox failure stops the build. |
| Scoped game capabilities | Expose only host-approved assets, input, rendering, audio, and save operations instead of ambient operating-system access. |
| Runtime resource budgets | Enforce memory caps and deadlines for running games. Signed memory limits and CPU deadlines apply to native workers and optional Wasm runtimes. GPU work has separate limits. |
Build here. Improve over time.
Source transparency also gives you control over the build. Compile on demand with configurable optimization settings, then rebuild when your settings or compiler tools change. Performance depends on the game, settings, and host runtime.
Check for creator-signed updates yourself or set periodic checks while the library is idle. Review each update before installing it; rebuilding uses the same source checks and isolated compiler boundaries.
What can a game access?
The runtime design starts with no ambient filesystem or network access. Games receive specific operations through a small host API. The host scopes those operations to the signed package permissions and explicit user selections.
- Assets: virtual paths inside the game's archive, rather than unrestricted access to your folders.
- Input, rendering, and audio: explicit game operations exposed by the host.
- Saves: host-scoped storage rather than arbitrary filesystem writes.
- ROMs: a signed manifest declares which ROM files must be supplied by the player. No ROM is fetched automatically; only the files selected by the player are shared read-only in the signed manifest’s order for that session.
- Chosen files: optional signed permissions declare file types and size limits. Import and export use your explicit file choice; games receive data and a filename, never a host path or access to a whole folder.
- Networking: off by default. A signed on/off permission enables bounded HTTPS and TCP/UDP operations, including internet and local-network addresses without endpoint allowlists. Games never receive direct socket access.
Installing a package runs no game code or package-provided install scripts. Source checks reject filesystem, network, process, and environment paths, compile-time file includes, macros, unsafe blocks, and foreign declarations. Source checks, compiler isolation, and runtime limits work together; inspection alone cannot prove a game harmless.
Game code uses the GamePKG API.
Game packages cannot use Cargo dependencies. This includes third-party crates and gamepkg-* crates. The host supplies gamepkg:: functions for input, scoped files, drawing, Slang shaders, textures, audio and achievements.
The rule applies when packing, verifying, installing and building. A signature or setting cannot enable a dependency. Creators can follow the developer instructions and game source policy.
Build your library at your own pace.
Your library tracks time played, locally earned achievements, and storage used. Signed game manifests can declare achievements and an estimated storage requirement; measured usage and creator estimates are shown separately.
The desktop library periodically checks installed games for verified updates. Settings controls the interval or disables checks. Available updates stay ready for your review; installation is always your choice.
Import a portable .gamepkgstore bundle to bring games and their shared assets into your library. Inspect the verified games and creator keys first, then approve installation.
Drag a .gamepkg or .gamepkglist file into the desktop library to open it. Packages still require creator review before installation.
Import a .gamepkglist to add many games without downloading them. Entries stay Not downloaded until you choose one. Catalog claims are unverified; the downloaded, signed package supplies the authoritative identity and permissions.
Download the port catalog, or import https://github.com/centrexity/GamePKG_Ports from the desktop library. Review each package’s requirements and creator before installation.
User-requested downloads support HTTPS and Tor onion URLs. Onion downloads go through a local Tor SOCKS proxy with remote DNS and no direct fallback. Host downloads and update checks do not grant game code network access.
Updates keep continuity with the creator key approved at installation. A signature proves integrity and key ownership, not a creator's real-world identity or the safety of their code.
Start playing: setup and quickstart →Download from a GitHub project
Enter https://github.com/owner/repository to download its latest published stable release. The release must contain exactly one .gamepkg file. A /releases/tag/version link selects a specific release; use a direct asset link when the project hosts multiple packages. GitHub project links also work in game catalogs and signed update URLs. For list or store imports, the app selects one matching .gamepkglist or .gamepkgstore release file. Package signatures, creator approval, and update checks still apply.