# CasaOS-AppStore-Play is a 130 app Docker Compose catalogue that keeps its images on latest

> CasaOS-AppStore-Play is a third-party CasaOS app store that also works for general Docker Compose deployment, with more than 130 applications, per-architecture source builds for arm, arm64 and amd64, and a deliberate use of the latest tag so images stay current without the store being maintained. It suits a self-hosted Docker user, and it explicitly is not suitable for official app store listing.

**Cp0204/CasaOS-AppStore-Play** — A Docker Compose Hub, Making Docker Your Productivity Tool - 一个 Docker Compose 仓库，让 Docker 成为你的生产力工具

- Repository: https://github.com/Cp0204/CasaOS-AppStore-Play
- Stars: 534 · Forks: 79
- Language: HTML
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/cp0204-casaos-appstore-play

## A third-party store that also works outside CasaOS

The project describes itself as a third-party CasaOS app store that also supports general Docker Compose deployment, and the repository description puts it plainly as a Docker Compose repository whose goal is making Docker your productivity tool.

That second half is the part that widens the audience. The entries under Apps/ are Docker Compose applications, and the store format is a convenience layer on top of them. Someone who does not run CasaOS can still take the Compose definitions and run them by hand, which is why the README calls the store a secondary identity rather than the product itself.

The catalogue is large, with the README describing rich third-party applications and 130 or more entries. The list includes 1Panel as a server management panel, Adminer for database management, AFFiNE as a local-first knowledge base, AList for file listing across multiple storages, AnythingLLM for a self-hosted chat interface over your own documents, Aria2 as a download utility, and both a CPU and an NVIDIA variant of the n8n AI starter kit. There is also dkTurbo at position zero, a Docker image accelerator that tests mirror speeds and applies the fastest one.

Two of the listed items carry a note about who should use them. dkTurbo is marked as unnecessary for non-Chinese users, since it exists to work around slow or blocked access to Docker Hub. And the n8n starter kit is listed twice, once for CPU and once for NVIDIA, pointing at different Compose files for the same product.

The primary language is HTML, which reflects that this is a catalogue of manifests rather than an application, and the last push to the repository was on 2026-08-17 with a single release tagged new at v20260814.

## The latest tag trick, and why the update check is disabled

The design decision that distinguishes this store from a conventional app catalogue is the use of the `:latest` tag on every image, and the consequences of that are spelled out in a note.

The store app uses the `:latest` tag, so the check for updates function in the upper right corner of the app is disabled, but you can manually edit the app settings once, without changing anything, to get the latest image. The stated benefit is that even if the store source is unmaintained, you can always get the latest version of the app.

That is a clever piece of engineering around a real problem. A CasaOS store source is a list of app definitions with version numbers, and if the maintainer stops updating the source, the apps in it stop moving even though the upstream images keep changing. Pinning to latest and disabling the version check inverts the dependency: the store's job becomes producing a working Compose file, not tracking versions.

The cost is the usual one. With no version in the image reference, there is no way to know which build you are running, no way to roll back to a known state, and no way for the store to tell you that an upstream release changed something. If an upstream image changes its configuration format, an app that worked yesterday can break without any change on your side.

The README is also clear that this store is unsuitable for official AppStore listing, which reads as a deliberate statement about how it is maintained rather than a passing remark.

## Per-architecture sources and the armv7 problem

The generic source is a zip file served over HTTPS, and the README recommends adding the architecture-specific variant if you can.

The generic one is at https://play.cuse.eu.org/Cp0204-AppStore-Play.zip, and it is described as just a generic version.

Three architecture-specific builds follow. The arm, armv7 and armhf variant is for arm, armv7 and armhf devices, and it does two things: it adds older versions of some applications that LinuxServer has dropped support for, and it fixes an issue where the official app store fails to install and upgrade. The arm64 and armv8 variant covers boxes like the S905xx and RK33xx. The amd64 and x86-64 variant covers ordinary cloud hosts and industrial machines.

```
  https://play.cuse.eu.org/Cp0204-AppStore-Play-arm.zip
```

```
  https://play.cuse.eu.org/Cp0204-AppStore-Play-arm64.zip
```

```
  https://play.cuse.eu.org/Cp0204-AppStore-Play-amd64.zip
```

The armv7 case is the interesting one, because LinuxServer has ended arm hf support, and the store keeps older image versions for the affected applications. That is a real service: it means an armv7 box, which is common in cheap home server and NAS hardware in China, can still install applications whose upstream maintainer has moved on. The same variant also patches the install and upgrade failure in the official store for those devices.

The repository layout reflects the split, with Apps/, Apps_arm/, Apps_arm64/ and Apps_pre/ as separate directories, plus a Tools/ directory, category-list.json, recommend-list.json, store-config.json and supported-languages.json at the root.

## The China network helper script

Folded into the README is a section about optimising for domestic network conditions, and it comes with a script that is worth understanding before you run it.

The description explains the problem it solves. After adding this software source to CasaOS and installing the dkTurbo application, you can use it to switch Docker image mirrors with one click, which solves the problem of installs hanging when pulling images fails, an issue the README dates to 20240606.

```bash
bash <(wget -qO- https://play.cuse.eu.org/casaos_newbie.sh)
```

The script is described as a helper for newcomers with several one-click functions, including changing the Docker Hub source and setting a proxy for docker pull. That is a script that modifies your Docker daemon configuration and network settings, fetched and piped into a shell from a remote host.

That is the standard pattern for convenience installers and it is also the reason to read it before running it. The command downloads and executes code from the project author's server at the moment you run it, with no version pin, and the operation touches the daemon's registry configuration and the proxy settings for image pulls, which affects every container operation on the host.

The README marks dkTurbo itself as unnecessary for non-Chinese users, and the helper script is part of the same feature. If your host reaches Docker Hub normally, the sensible reading is that you do not need either.

## The TODO list says where the project is going

The TODO section is short and it is the clearest statement of the project's direction, since the stated plan is to convert the repository into a general purpose Compose repository.

Two items are already done. All $AppID variables have been cancelled, which removes the CasaOS-specific identifier that a plain Compose file does not need, and that is a concrete step toward the general repository goal.

Two remain. One is a one-click script for choosing which applications to install, and the other is adapting fields for dockge.

The dockge item is worth pausing on, because dockge is a Compose management interface, and adapting the field format for it is a step towards serving users who never open CasaOS at all. That matches the stated direction and it is consistent with the repository already listing 1Panel as an application, which is a different server panel with the same intent.

So the project is mid-transition: it began as a CasaOS store, it is becoming a Compose catalogue with a CasaOS store format on top. The Apps/ directories and the JSON files at the root are the store format, and the Compose files inside each app directory are the part that will outlast it.

## Sponsorship and infrastructure behind the store

Two practical notes about what runs the service.

The first is funding. The README asks for a coffee if you enjoyed the project, and links a PayPal donation, a Buy Me a Coffee button and a WeChat Pay code. For a project maintained by one person with 130 applications to keep consistent, that is the actual cost model.

The second is CDN acceleration and security protection, sponsored by Tencent EdgeOne. The README credits it as the best Asian CDN, edge and security solution.

That is a meaningful detail for a project serving users across China and elsewhere, since the source zips and the helper script are hosted on play.cuse.eu.org and delivered through a CDN with edge caching. It also explains the region-specific script and the mirror accelerator, both of which exist because the default path to Docker Hub is slow or unreliable from some networks.

The repository also ships a Proudly-Using-CasaOS-AppStore-Play.md file, which is the list of users who have put their installation in the README, which is the usual currency of this kind of project.

The licence for the repository is recorded as unknown, with no licence file among the top-level entries. That is a real gap if you intend to reuse the Compose definitions in a commercial context, and it is worth raising with the maintainer rather than assuming the same terms as the upstream applications, which carry their own.

## Where CasaOS-AppStore-Play is the wrong choice

Four cases argue against it.

The first is a need for reproducible deployments. Every app uses the latest tag, so two installs a week apart can be running different builds of the same application, and there is no version to roll back to. For a home server that is often acceptable. For anything you might have to rebuild, or where a silent upstream change could break a working setup, it is not.

The second is if you are outside China and can reach Docker Hub. The primary value of this store for many of its users is the mirror accelerator and the domestic network workarounds, and the README explicitly says non-Chinese users do not need dkTurbo. Elsewhere the catalogue is still useful, but you are paying for a convenience wrapper rather than a network fix.

The third is a production deployment where the licence matters. The repository records no licence, so there is no stated permission for redistribution, and no warranty about the state of any individual app definition.

The alternative in the same direction is a general Compose catalogue of your own, which for most people means writing a small docker-compose.yml and a .env file for each service. The difference in approach is that this store gives you 130 working configurations, per-architecture handling and a house format for the CasaOS interface, while your own file gives you pinned versions, your own volumes and network layout, and no third party in the middle. If you run three or four services, writing them yourself is an afternoon. If you run fifteen and you want one-click updates, the store is the reason it exists.

## Conclusion

CasaOS-AppStore-Play fits a self-hosted Docker user on CasaOS who wants a large catalogue of one-click installs, or who wants the same Compose files outside CasaOS entirely. It does not fit a user who needs reproducible image versions, because every app is pinned to the latest tag and the update check is disabled by design. Add the source URL `https://play.cuse.eu.org/Cp0204-AppStore-Play.zip` in CasaOS, or the arm, arm64 or amd64 variant for your architecture, and expect to edit an app's settings once to pull the newest image.

## FAQ

### What is CasaOS-AppStore-Play?

It is a third-party CasaOS app store that also supports general Docker Compose deployment, with more than 130 third-party applications. The repository's stated direction is to turn it into a general purpose Compose repository.

### How do I add the CasaOS-AppStore-Play source?

Add the zip URL in CasaOS. The generic source is `https://play.cuse.eu.org/Cp0204-AppStore-Play.zip`, and for better support you should add the variant matching your architecture: the arm, armv7 or armhf build, the arm64 and armv8 build, or the amd64 and x86-64 build.

### Why does the store use the latest tag?

Because it removes the dependency on the store being maintained for updates. The check for updates function is disabled in the app, but you can manually edit the app settings once without changing anything to get the latest image, so the applications stay current even if the store source goes unmaintained.

### What does the arm variant of the store add?

The arm, armv7 and armhf source adds older versions of some applications that LinuxServer has dropped support for, and it fixes an issue where the official app store fails to install and upgrade on those devices. It is aimed at hardware such as domestic set-top box devices.

### Can I use these Docker Compose files without CasaOS?

Yes. The project states that it also supports general Docker Compose deployment, and each entry under Apps/ is a Compose definition with its own icon and description. The store format is a convenience layer over the manifests rather than the product itself.

## Sources

- [Cp0204/CasaOS-AppStore-Play on GitHub](https://github.com/Cp0204/CasaOS-AppStore-Play)
- [Issues](https://github.com/Cp0204/CasaOS-AppStore-Play/issues)
- [README](https://github.com/Cp0204/CasaOS-AppStore-Play/blob/main/README.md)
- [Releases](https://github.com/Cp0204/CasaOS-AppStore-Play/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cp0204-casaos-appstore-play
