Eight.ly App Catalog
Stop rebuilding the same installation.
Self-hosting too often starts with a search for someone else's deployment file. We built a catalog of one-command containers so the repeatable parts of installation can be prepared once and used again.
Explore Eight.ly- 464+one-command apps
App Catalog inventory, October 2026; counted separately from Eight.ly Templates.
- 1 commanda repeatable app installation
The Eight.ly App Catalog packages its 464+ apps for one-command deployment.
- Readable definitionsdeployment as a maintained file
The documented Compose approach keeps images, networks and storage choices inspectable.
- Choose an appStart from a maintained container definition.
- Set host valuesSupply the paths, ports and settings for this installation.
- DeployStart the application with its declared data mounts.
- Finish setupComplete the application's own account and integration choices.
The problem
The difficult part of self-hosting is often the wiring around the application: image selection, folders, ports, permissions and network names. Rebuilding that wiring from snippets makes each new installation slightly different from the last.
A reusable catalog has to preserve choices that matter. A local service exposed through an IP address does not need the same routing configuration as one behind a domain and sign-in. Application data must also stay separate from the disposable container.
Who it’s for
For people assembling their own servers and media stacks, and for organisations that need the same application deployed consistently across more than one machine.
What we built
Our App Catalog packages 464+ apps as one-command containers. This collection sits alongside the larger Eight.ly Templates library, with a focus on repeatable container deployments and the setup those deployments share.
The underlying deployment approach is deliberately inspectable: application definitions describe how the container runs, where its files live and how other services reach it. We apply that approach across the Eight.ly and HomelabARR work rather than treating the app itself as a black box.
How it works
A deployment definition captures the repeated setup work, then configuration supplies the values specific to a host. The container starts with its declared network and mounted data paths. The result is a repeatable starting point for the application's own setup.
That distinction matters for a media stack. Bringing up the containers does not automatically configure every indexer, library and account. The apps still need their own first-run choices, and consistent shared paths are what let them work together afterward.
What was hard
Catalog work is dependency work. In earlier HomelabARR catalogue maintenance, we replaced plugin-dependent host volumes across 77 templates with native mounts and checked a clean installation. That experience informs how we approach app definitions: remove hidden prerequisites and make the storage choices inspectable.