Zeno is a fully client-side application with no backend, which gives it broad deployability but also comes with constraints inherited from the browser APIs it relies on. The limitations below are known and, where possible, Zeno works around them automatically — but understanding them helps you avoid surprises.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xXmizzeryXx/zenodeployment/llms.txt
Use this file to discover all available pages before exploring further.
Storage and persistence
Clearing site data removes all saved games
Clearing site data removes all saved games
Games are stored in IndexedDB and settings in localStorage. Both are scoped to
the browser origin. If you clear site data from your browser’s DevTools or
privacy settings, all saved games and preferences are permanently deleted —
there is no cloud backup or export.Back up games you want to keep by keeping the original files accessible before
clearing storage.
Very large games may hit IndexedDB storage quotas
Very large games may hit IndexedDB storage quotas
IndexedDB storage is shared with the browser’s general per-origin quota. Very
large games (hundreds of MB in total assets) may fail to save if the available
quota is exhausted. The exact limit depends on the browser and available disk
space.If a game fails to persist, check storage usage in DevTools → Application →
Storage to see how much quota is in use and what is available.
Service Worker memory
SW in-memory store resets on SW restart
SW in-memory store resets on SW restart
The
fileStore Map inside zeno-game-sw.js lives in the SW’s JavaScript
heap. Browsers terminate idle service workers to reclaim memory, which clears
the Map. Any registered games are gone until re-registered.Zeno handles this automatically: before launching a game, it sends a
PING_GAME message. If the SW responds with GAME_MISSING, Zeno re-registers
the game from the copy stored in IndexedDB before opening the iframe. This is
transparent to the user — no manual action is required.Git import
GitHub rate limit: 60 unauthenticated requests/hour
GitHub rate limit: 60 unauthenticated requests/hour
Zeno uses the GitHub API without authentication. GitHub allows 60 API requests
per hour per IP address for unauthenticated clients. Each repo scan uses
2 requests (repo info + file tree), so you can scan up to 30 repos per
hour before hitting the limit.If you hit the rate limit, wait for the hour window to reset, or use a
GitLab or Forgejo source instead — they have separate rate limits.
Network-restricted environments may block raw.githubusercontent.com
Network-restricted environments may block raw.githubusercontent.com
Downloading game files from GitHub repositories requires access to
raw.githubusercontent.com. School networks, corporate proxies, and some
content filters block this domain.Use git.gay, codeberg.org, or another accessible Forgejo/Gitea instance
as your game source in restricted environments.Nested games are not detected
Nested games are not detected
The Git import scanner only looks for
index.html in top-level folders of
the repository. A game at games/subgame/index.html (two levels deep) will
not be detected.Structure repos so each game is a direct child of the repository root.Single-game repos require index.html at the root
Single-game repos require index.html at the root
If a repository contains a single game rather than multiple game folders, the
scanner detects it only if
index.html is present at the repository root.
A root-level index.html causes the repo itself to be listed as a game using
the repository name.