Ownfoil: a self-hosted Switch library manager and Tinfoil shop
Nintendo Switch library manager, with automated management tasks, serving your library to multiple supported clients on your Switch, with shop customization and multi user authentication.
At a glance
- What is it?
- Ownfoil indexes a local Nintendo Switch library, fills in missing updates and DLC, and serves it to Tinfoil, Sphaira and CyberFoil over HTTP. It is a Python application, AGPL-3.0 licensed, and the README is explicit that no prebuilt executable exists.
- Who is it for?
- Adopt Ownfoil if you already keep Switch content on your own disks, are willing to run a container or a uv environment, and want Tinfoil, Sphaira or CyberFoil pointed at a library you control. Do not adopt it if you want a signed binary you can double-click, or if you expect the project to source content for you.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Ownfoil fills between a folder of files and a working shop
A Switch library on disk is rarely tidy. Updates and DLC arrive as separate files with names that do not always match the base game, and the console-side clients that install content expect an index, not a directory listing. Ownfoil sits in that gap. The README describes it as a library manager that also turns the library into a self-hosted shop supporting multiple clients, with the stated goal of managing the library, identifying missing content such as DLCs and updates, and giving a user friendly way to browse and install that content. The audience is narrow and specific: people who already hold Switch content locally, run something at home or on a small server, and want their console to see a catalogue rather than a file share. It is not a storefront, not a downloader, and the README carries a caution block stating there is no website associated with the project and that Ownfoil is not released as an application or an executable file, with an instruction not to download or execute anything related to Ownfoil outside the repository and its instructions. That warning matters more than usual here, because the project name sits in a category where lookalike binaries are plausible.
How the library pipeline actually works: identify, organise, verify, compress
The mechanism visible in the material is a pipeline over local files. Content identification runs either through content decryption or through the filename, which is a meaningful fork: the decryption route needs console keys, and the README lists console keys management as a feature, so keys are stored and handled by the application rather than passed in per run. The filename route avoids that dependency but is only as reliable as the naming convention in your collection. Once identified, the automatic library organization, verification and compression step takes over. Compression is credited to the nsz format and the nsz tool by nicoboss, so the project is not inventing a container format; it is driving an existing one. Identification is also what makes the missing-content feature possible, since knowing which base titles are present is a precondition for reporting which updates and DLC are absent. The web interface serves two roles at once: configuration and browsing. On the serving side, the README names Tinfoil, Sphaira and CyberFoil as supported clients, each pinned to a version in the badges (Tinfoil v20.0, Sphaira v1.0.6, CyberFoil v1.4.5), which tells you the project tracks client protocol changes rather than assuming a stable interface. Multi user authentication and shop customization sit on top of that, so the same library can be exposed differently to different accounts.
Installation paths, and why the Windows one is different
The README does not inline the install steps; it points to Install.md, which lists five routes: Docker, uv, Unraid, Proxmox LXC, and a Helm chart. The uv entry carries a parenthetical instruction to Windows users to do this, which is the clearest signal in the material that the Docker path is not the recommended one on that platform. In practice that means a Windows host runs Ownfoil as a Python application in a uv-managed environment rather than in a container, and the rest of the world picks between a plain container, an Unraid template, an LXC container on Proxmox, or a Kubernetes deployment via Helm. Configuration itself is documented separately in Usage.md, which opens with a First steps section and also provides a settings reference. The README does not reproduce individual config keys, so anyone planning a deployment should read Usage.md rather than guess at environment variables, and should treat the settings reference as the authoritative list. The published Docker image covers amd64, arm64/v8, arm/v7 and arm/v6 according to the platform badge, so small ARM boxes are a supported target rather than an afterthought.
The console keys dependency is the sharp edge
Content decryption requires keys from the console, and the README lists console keys management as a feature without describing what happens when keys are absent, wrong, or from a different firmware generation. That is the failure mode worth planning around. If identification falls back to filename parsing, a library with inconsistent naming will produce partial or incorrect results, and partial identification degrades the missing-content report, which is one of the project's main selling points. Compression is the second constraint. Re-encoding a library into nsz is not free in time or in temporary disk space, and the README gives no figures for either, so the honest position is that the cost is unknown from the documentation and should be measured on a small subset before pointing the tool at a full collection. There is also a scope limit that is easy to miss: Ownfoil organises and serves what you have. It does not acquire content, and nothing in the README suggests otherwise.
Ownfoil against a plain file server or a static Tinfoil index
The obvious alternative is putting the same files behind a generic HTTP server or a NAS share and generating a static index by hand. The difference is where the work happens. A static setup treats the library as a set of files and asks the client to cope; Ownfoil treats the library as records, which is what makes missing-update and missing-DLC reporting possible at all, and what allows per-user authentication and shop customization instead of one undifferentiated directory. The trade is operational: a static file server has no Python runtime, no keys, no compression step and no version coupling to Tinfoil, Sphaira or CyberFoil. If your collection is small, consistently named, and you are the only user, the static route is less to maintain. Ownfoil earns its complexity when there are multiple users, when the library is large enough that gaps are hard to spot by eye, or when you want the console to see a curated shop rather than a dump.
Maintenance, release cadence and the AGPL-3.0 question
The release history shows a steady cadence: 2.4.0 in mid-August 2026, 2.4.1 in early September 2026, and a separate titledb data release between them. That last item is the maintenance detail people underestimate. The titledb artifact is versioned independently of the application, which implies title metadata is refreshed on its own schedule and that a stale titledb will affect identification quality even on a current application build. Budget for updating both. The licence is AGPL-3.0, which in plain terms means that if you modify Ownfoil and let other people interact with it over a network, the source of your modified version has to be offered to them. Running an unmodified copy for your own household does not trigger that. This is a description of the licence's usual effect, not legal advice; if you plan to expose a modified build to anyone outside your home, read the licence text or ask someone qualified. The README's credits point to Tinfoil, Fs, the nsz format and TitleDB from blawar, the nsz tool from nicoboss, and NSTools from seiya-dev, so a meaningful share of the technical foundation is external and its health affects Ownfoil's.
Who should run this, and what to check before the first scan
Ownfoil fits the self-hoster who already has content on disk, is comfortable with Docker or a uv environment, and wants a single place to see what is missing and to serve it to a console. It does not fit anyone who wants an installed program, and the README's own caution block is the reason: there is no official binary, so any executable claiming to be Ownfoil is outside the project. Before the first full scan, confirm that your keys are in place if you intend to use the decryption path, and test the compression step on a handful of files to get a real sense of the time and temporary space it needs, since the documentation does not state either. Then read Usage.md's settings reference rather than improvising configuration. The judgement is straightforward: this is a tool for people who treat their Switch library as something worth curating, and it is priced accordingly in setup effort.
Editorial conclusion
Adopt Ownfoil if you already keep Switch content on your own disks, are willing to run a container or a uv environment, and want Tinfoil, Sphaira or CyberFoil pointed at a library you control. Do not adopt it if you want a signed binary you can double-click, or if you expect the project to source content for you. Before committing, verify three things: that your console keys are available for the decryption path, that your storage can absorb the compression working set, and that the AGPL-3.0 network clause is acceptable for how you intend to expose the shop.
Community notes