Big Bear CasaOS is a third party app store for CasaOS and ZimaOS

A parallel store that ships with the hardware

IceWhale builds CasaOS for home servers and ZimaOS for the ZimaBoard hardware, and both ship with an app store of their own. The Big Bear CasaOS app store comes pre-installed alongside that vendor store, and it is developed and maintained independently by BigBearTechWorld and the BigBearCommunity. The project states plainly that it operates as a completely separate and independent project from IceWhale, and that IceWhale does not fund it. That independence is the defining feature and also the risk, so it is worth stating early: you are adding a catalogue maintained by one organisation to a platform built by another, and the two do not share a release schedule or a support contract. The project also describes itself as the default option on all IceWhale hardware, and as the most up-to-date third party store for those platforms. The catalogue claims 200+ applications for CasaOS and ZimaOS, along with 134+ video tutorials in the maintainers' CasaOS playlist.

The store is distributed as a zip of the master branch

There is no package to install and no release to pin. The store is published as an archive URL that points at the master branch, and that URL is what a CasaOS instance consumes as an app store definition.

https://github.com/bigbeartechworld/big-bear-casaos/archive/refs/heads/master.zip

The consequence is architectural. Because the address always resolves to the current tip of master, an instance that adds this URL does not receive a stable snapshot of the catalogue. It receives whatever the branch holds at the moment it syncs, and it receives whatever the branch holds at the moment it syncs again later. The repository carries an auto-sync-platforms workflow alongside a general CI workflow, which is consistent with a model where the branch is the source of truth and platforms pull from it. For anyone who wants reproducible installs or a pinned catalogue version, that is a real limitation, and it is one you have to work around, since the repository publishes no GitHub releases to version against. The upside of the same design is that new applications and updated container versions appear without anyone maintaining a mirror.

What actually lives in the repository

The repository is mostly data with a small amount of tooling wrapped around it. The Apps directory holds the application definitions, each entry pairing an application name with a Docker image, a version string, an optional video link and an optional docs link, and the README table shows the shape of those records: 2fauth on image 2fauth/2fauth at version 8.0.2, authentik on ghcr.io/goauthentik/server at 2026.2.2, appsmith on appsmith/appsmith-ce at v2.5.0. Alongside Apps/ sit the JSON configuration files that shape the store: store-config.json for store level settings, category-list.json for browsing categories, recommend-list.json for the recommended section, supported-languages.json for localisation, and config.json. templates/ holds the templates used when an entry is created, and the images/ directory holds assets including a default-icon.svg file used when an entry has no artwork of its own. The scripting layer is thin and mostly JavaScript and shell: convert-apps.sh, create-prs.sh, sync-apps.sh, and a jest.config.js alongside a tsconfig.json, which tells you the definitions are validated by tests rather than by hand.

The recommended list is sold, and that shapes what you see

This is the part of the project that deserves attention before you install it, because it affects what the store shows you. BigBearTechWorld sells placements in the recommended apps list at three monthly tiers: Basic Placement at 50 dollars a month, which includes inclusion in the recommended list with regular updates and maintenance, Premium Placement at 150 dollars a month for a prominent position, a featured mention in community updates and priority support, and Featured Partner at 300 dollars a month for top placement with a highlighted entry, a dedicated YouTube video and monthly mention in community updates. Sponsorship is handled through the maintainers' Ko-fi membership levels. The practical effect is that the recommended section of the store is not a neutral ranking. It is a paid list whose order reflects tier. The plain catalogue, by contrast, is a community contribution, with app suggestions handled through the BigBearCommunity server and contributions going through pull requests. If you rely on the recommended list to decide what to install, you should read it as advertising rather than as an editorial ranking.

The maintenance toolchain behind the catalogue

The package manifest shows a JavaScript toolchain rather than an application runtime. The scripts section defines generate-readme, which runs a TypeScript generator through bun, commit, which wraps git-cz for conventional commits, lint, which runs eslint across the apps directory as JSON with a schema validation plugin enabled, and test, which runs jest. There is a commitlint configuration with a conventional preset, husky for git hooks, prettier for formatting, js-yaml for reading YAML definitions, semver for version handling and glob for file discovery, all in devDependencies because none of it ships to a runtime. Two files stand out for understanding how the catalogue stays current. renovate.json indicates dependency update automation across the image references, and the sync and pr creation scripts indicate that entries are added or refreshed and pushed upstream as changes rather than edited by hand one at a time. The last push to the repository was on 2026-10-22, and the project is not archived.

The licence metadata does not agree with itself

Two licence statements exist in this repository and they conflict. The project page shows MIT, and the LICENSE file at the top level matches that, while the package manifest for the same project declares GNU General Public License v3.0 in its license field. For the catalogue itself, where the content is a list of image references, the practical difference is small. It becomes a real question if you take the definitions, the templates or the generator and reuse them in a product you distribute, because the two grants have different obligations, and this is not legal advice so treat the point as a flag rather than a conclusion. The cleanest resolution is to ask the maintainers which licence they intend, since the manifest and the repository metadata can disagree for years without anyone noticing. The same caution applies to the applications themselves, since each entry points at a third party image with its own licence that the catalogue does not restate.

When the catalogue is the wrong tool

There are cases where adding this store solves nothing. If you run one or two services and already have a compose file for them, the catalogue adds a dependency on somebody else's release cadence in exchange for a nicer install button. If you need an application that is not in the list, the catalogue does not help, since the store only carries what has been contributed. If you want pinned versions for reproducibility, the master branch archive model works against you. And if you are running a plain Linux server with Docker rather than CasaOS or ZimaOS, none of this applies, because the store format is tied to the IceWhale platforms. The alternative worth naming is the plain Docker Compose route: you write your own compose file, pin the image tag yourself, and manage updates through your own tooling. You give up the one click install and the category browsing, and in exchange you get version control over every dependency in the stack, which is what you want if the store is going into production.

Editorial conclusion

Big Bear CasaOS is worth adopting on CasaOS and ZimaOS if you want one click installs for self hosted services and do not mind that the catalogue is maintained outside the vendor, with sponsorship tiers deciding what appears in the recommended list. It is the wrong choice if you need a curated store you fully control, if a GPL notice in the package manifest is a problem for your compliance process, or if you want release notes for the store itself, since the repository publishes no GitHub releases. Verify two things before you point CasaOS at it: that the app definitions under Apps/ match the container versions you intend to run, and that the licence situation is acceptable to you, since the project page lists MIT while package.json declares GNU General Public License v3.0. The practical first step is adding the master branch archive URL in the CasaOS app store and checking that one non critical application installs and starts as expected.

Frequently asked questions

Official sources

1. bigbeartechworld/big-bear-casaos on GitHub
2. Issues
3. License: MIT
4. Project website
5. README