Play games safely.
Know what you run. Control what it can access.
GamePKG is building a safer way to share and play games: inspectable source, creator-signed packages, isolated compilation, and a host designed to grant only the capabilities a game needs.
Download for Linux Download for WindowsVerify your download with the release checksums. Windows source builds use a matching Linux compiler inside WSL 2; playback runs in the native Windows app. 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 ships.
Review the source, creator fingerprint, permissions, and any user-provided ROM requirement.
Keep the build isolated.
Verify signed contents and compile verified source in a private, network-isolated Linux work area, including through WSL 2 on Windows.
Grant specific access.
The Wasm host exposes scoped assets, selected ROMs, saves, drawing and audio through a versioned WIT component API or the legacy core profile, with fuel, memory and deadline limits.
Limits that belong in the format.
| Protection | What it controls | Status |
|---|---|---|
| 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. | Available |
| Bounded archive access | Reject traversal paths, duplicate entries, symlinks, and oversized archive contents. Read assets from the archive without extracting the whole game. | Available |
| Restricted source profile | Checked Rust source modules, approved pinned dependencies, no build scripts or procedural macros, and Slang-only shader source. Every packaged Rust file is scanned. | Available; scanning alone is not a sandbox |
| 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. | Available for checked source modules and pinned dependencies |
| Scoped game capabilities | Expose only host-approved assets, input, rendering, audio, and save operations instead of ambient operating-system access. | Available in core and versioned WIT component profiles |
| Runtime resource budgets | Enforce memory caps, execution fuel, and deadlines for running games. Signed memory and fuel limits apply in both runtime profiles. GPU work is not metered by Wasm fuel. | Enforced for both Wasmtime profiles |
Build here. Improve over time.
Building games on demand on your own machine creates opportunities to optimize for the supported platform and runtime. Shipping source lets the host rebuild as compiler tooling and optimization settings improve, while creators can deliver signed source updates.
The host can also check periodically for newer versions while preserving continuity with the creator key you approved. Local compilation and updates remain subject to the same package restrictions and sandbox boundaries.
Today: isolated Wasm builds, rebuilds, user-requested update checks, and configurable periodic checks while the desktop library is idle. Broader platform-specific performance tuning remains planned. Local builds are not guaranteed to outperform prebuilt games.
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.
- Networking: guest networking is unsupported. Current manifests must declare
network = "none".
Installing a package runs no game code or package-provided install scripts. The initial scanner rejects detected filesystem, network, process, and environment paths, compile-time file includes, unsafe blocks, and foreign declarations. Compiler isolation remains necessary because source scanning cannot prove what arbitrary macros will do.
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. Settings also controls approval of bundled game libraries.
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.
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 distributes multiple games. 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.