# Pi-Apps: a Raspberry Pi app store built from shell scripts instead of packages

> A GPL-3.0 collection of install scripts for ARM Linux that sidesteps packaging formats entirely, ships a GUI front end, and declares support for Pi boards, Switchroot, Jetson and generic ARMv7 to ARMv9 devices.

**Botspot/pi-apps** — Raspberry Pi App Store for Open Source Projects

- Repository: https://github.com/Botspot/pi-apps
- Stars: 2,834 · Forks: 286
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/botspot-pi-apps

## A shell script store with no packaging format

The repository's whole pitch is in one paragraph of its README: Pi-Apps is a well-maintained collection of scripts that automatically install hard-to-install apps, and it is not your average app store. Rather than require any standardized packaging format or centralized hosting, the scripts download each app from where it already is. The upstream language is Shell, the licence is GPL-3.0, and the repository currently carries 2,815 stars, 279 forks and 151 open issues on the default branch, master. That combination, GPL plus a fork count in the hundreds, is worth pausing on, because a fork is the natural unit of contribution for a script store. You do not need to write an app or be its developer to submit one. The README says so directly: you just have to know a little bit of bash scripting. That single sentence explains the shape of the project better than any architecture diagram would. A package format needs a build system, a dependency solver, a signing story and a hosting budget. A script needs a download URL and some case statements. Pi-Apps takes the trade deliberately, and the 200-plus apps in the catalogue are the evidence that the trade holds often enough to be useful.

## What the install one-liner actually does

Installation is a single line, and it is worth reading as a security decision rather than a convenience:

```bash
wget -qO- https://raw.githubusercontent.com/Botspot/pi-apps/master/install | bash
```

This is a pipe from the network straight into a shell. There is no file you inspect first, no checksum to compare and no prompt that tells you what is about to happen. That pattern is extremely common in Linux installer tooling, and it is the main thing to think about before running it. The project ships its own installer script at the top level of the tree, alongside a `manage` script, an `uninstall` script and an `updater` script, so the alternative is available if you would rather read the code before executing it. Cloning the repository first and inspecting the `install` file costs one command and removes the blind trust entirely:

```bash
git clone https://github.com/Botspot/pi-apps.git
cd pi-apps
ls
```

The top-level listing is short and tells you what the project considers its own vocabulary. Alongside `install`, `manage`, `uninstall` and `updater` you get `api`, `apps`, `createapp`, `data`, `etc`, `gui`, `icons`, `preload` and `settings`. Four of those are scripts you can run and the rest are directories. There is no Makefile, no package.json and no requirements.txt, which is consistent with a project whose entire job is to run shell commands on someone else's machine.

## The repository layout and what each top-level script is for

The tree is flat enough to read in one pass and the names are self-describing. `apps` is the catalogue itself, one entry per installable program. `createapp` is the contribution path, the script a new submission starts from. `data` and `etc` hold the state and configuration that let the system remember what it installed, which is the piece that separates a real app store from a folder of one-off installers. `gui` is the graphical front end, and its presence is the answer to the obvious objection about shell scripts being unfriendly. `icons` holds the images that front end and the website draw from. `api` and `preload` sit alongside them as the plumbing, and `settings` is where configuration lives. Two files outside that set are worth calling out because they are unusual for a shell project. `AGENTS.md` and `CLAUDE.md` sit at the root, alongside `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `COPYING` and `CHANGELOG.md`. Two agent instruction files in a Raspberry Pi installer repository means the maintainers expect automated tooling to participate in contributions, and that is consistent with a project whose contributor base is broad and casual rather than a small team of regulars. The presence of a `SECURITY.md` alongside them is the other signal, and a fair one: a script that fetches installers from the open internet is a meaningful privilege, and the project appears to acknowledge that in writing.

## The hardware support matrix is the honest part

Most project READMEs avoid naming what they do not work on. This one has a support matrix with two explicit levels, and the weaker level is labelled rather than omitted. Raspberry Pi 2 v1.2, Zero 2 W, 3, 4 and 5 are listed as fully supported, running Raspberry Pi OS in 32-bit Bookworm, 64-bit Bookworm or 64-bit Trixie, plus Ubuntu on Jammy and Noble. The list then extends well past the Pi: Nintendo Switch under Switchroot L4T Ubuntu Noble 24.04 and Jammy 22.04 are fully supported, and so is Nvidia Jetson on Jetpack 7 with Ubuntu Noble and Jetpack 6 with Ubuntu Jammy. Then the level drops to a warning for Ubuntu Asahi on Apple Silicon Macs, which the README describes as not actively tested but where all available apps should work. The broadest tier covers Pine64, Orange Pi, Radxa, Banana Pi, Khadas, Inovato, Libre Computer and other ARMv7, ARMv8 and ARMv9 devices running Debian Bookworm or Trixie, with the significant qualifier that it means official releases from Debian only. Read that list as a description of where the script patterns have been exercised. Every script in the catalogue does the same work: fetch an artefact, check it, unpack it somewhere, link a binary, adjust a path. On a Pi that has been done hundreds of times. On an unofficial ARM board image with a different libc and a different desktop, the same script is doing the same work in a place nobody has tested it.

## The catalogue, the user claim, and what a submission costs

The README claims Pi-Apps serves over 1,000,000 people and hosts over 200 apps, and it links the full list off-site at pi-apps.io rather than duplicating it in the repository. That separation is itself a design decision worth noting: the repository holds the scripts, the website holds the searchable index, and the changelog gets its own file so history does not crowd the README. For contributors, the path the README describes is to script an install yourself, by hand or semi-automatically, then convert that into a submission. The `createapp` script is the starting point for that. The result is a catalogue whose quality is bounded by how carefully each contributor cleaned up their own manual install, which is a real quality spread, and one that the maintainers cannot fully flatten. It also means the catalogue skews toward whatever people wanted on their own board, which is why it covers media, development tooling and self-hosted services rather than whatever a distributor's priorities would have picked. The topic tags on the repository reflect that contributor-driven shape, including app-store, arm64, gui, gui-script, install, installer, pi-apps, raspberry-pi, raspbian and uninstall. Read the tag list as a table of contents for what kind of software this is: GUI applications on ARM hardware, installed and uninstalled by hand.

## Where a script-based store strains

The failure mode of this model is specific and predictable, and it is worth understanding before you install anything. A package manager gives you dependency resolution: if app A needs library B, the solver finds B or tells you it is missing. A script store gives you the command a person typed, which means the person had to have B installed already, or the script has to fetch B too, and now you have two installers racing over the same library. Updates are the second problem. A package has a version and a changelog and a repository index; a script has a URL that either still resolves or does not, and the failure surfaces as a broken app rather than a clear message. Uninstall is the third, and it is the one people feel most: Pi-Apps ships an `uninstall` script and an `updater` script, but a script that edited a config file by appending cannot always un-edit it. `data` and `etc` in the tree suggest the project tracks what it changed so removal can be cleaner than that, and the `gui-script` topic tag suggests some of that bookkeeping is exposed to the interface. None of this makes the project bad. It makes it a good fit for a machine you are willing to rebuild from an SD card image and a poor fit for a machine holding anything you would miss. Judge it on that axis, and check whether the specific app you want has a script before you install the store at all.

## Conclusion

Pi-Apps is worth installing on a spare Raspberry Pi that you are willing to reflash, and worth reading before you install it on a machine that is not. Its bet is that a shell script can install anything a human could install by hand, which is true far more often than a package format could be, and false in exactly the cases that matter when a machine holds real work. The GPL-3.0 licence, the 279 forks, the 151 open issues and a commit on 2026-09-24 point to a project with people in it rather than a finished utility, so expect rough edges and expect to file them.

## FAQ

### How do I get Pi-Apps on my Raspberry Pi?

Open a terminal and run one command: the installer is piped from the repository's raw master branch straight into bash. The alternative is to clone the repository and inspect the install script before running it, which costs a git clone and a read.

### What are some good programs to install on a Raspberry Pi?

Pi-Apps hosts over 200 apps and publishes the browsable list at pi-apps.io rather than in the README, with categories covering GUI apps, development tooling and self-hosted services. The catalogue is chosen by contributors rather than a distributor, so it tracks what people actually wanted to install on ARM hardware.

### Does Pi-Apps install apps through apt or a package format?

No. The README is explicit that Pi-Apps requires no standardized packaging format and no centralized hosting: each script downloads the app from where it already is. That is why an app can be added without being its developer, and why you only need to know some bash to contribute one.

## Sources

- [Botspot/pi-apps on GitHub](https://github.com/Botspot/pi-apps)
- [Issues](https://github.com/Botspot/pi-apps/issues)
- [License: GPL-3.0](https://github.com/Botspot/pi-apps/blob/master/LICENSE)
- [README](https://github.com/Botspot/pi-apps/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/botspot-pi-apps