You built a CLI tool. It runs great on Termux. Now you want other Termux users to install it with one command instead of git clone, dependency hunting, and "it doesn't compile on my phone."
Then you open a pull request to the official repository, and it gets closed. Or you try TUR and the review stalls. You're not alone, and it doesn't mean your tool is bad. It usually means the tool doesn't fit that channel.
This guide walks through every realistic way to distribute your own tools on Termux, what each one expects from you, and how to pick the right one.
Disclosure: I maintain Termux App Store, one of the options below. It is an independent community project and is not affiliated with the official Termux project. I'll be upfront about trade-offs for every option, including mine.
TL;DR
| Option | Best for | Review process | Users install with |
|---|---|---|---|
termux-packages (official) |
Widely used, stable, general-purpose software | Strict, maintained by the core team | pkg install |
| TUR (Termux User Repository) | Packages that don't fit official but still need a curated home | Curated contributor workflow |
pkg install (after enabling the repo) |
| Your own APT repository | Full control, your own release cadence | None (you are the reviewer) |
pkg install (after users add your repo) |
| Termux App Store | Niche, experimental, or fast-moving community tools | Pull request with validation tooling | termux-app-store install |
| GitHub release + install script | Quick start, small audience | None | `curl ... \ |
If you only read one line: start by asking who your users are and how much control you want over releases, then choose.
Why your package may get rejected
Official and curated repositories exist to protect users and reduce maintenance load. A few common reasons a new tool doesn't fit:
- Scope. The official repo targets software with broad use. A small or niche tool may not meet that bar.
- Maintenance burden. Every package needs someone to keep it building across architectures when Termux's toolchain changes.
- Build reproducibility. Packages must build from source inside the Termux build environment, not just run on your phone.
- Upstream fit. Projects with bundled binaries, unusual licensing, or heavy patching are harder to accept.
None of this is a judgement on your code. It's a question of which channel matches your project.
Option 1: The official {% raw %}termux-packages repository
The build system and primary set of packages for Termux live in termux/termux-packages. Packages are organized into repository channels such as main, root, and x11, and each package is a directory with a build.sh.
Choose this if your tool is stable, widely useful, and you're willing to maintain it long term.
Do this first: read CONTRIBUTING.md and the Developer's Wiki in that repo. Check whether a similar package already exists, and make sure your project has a clear license and tagged releases.
Option 2: TUR (Termux User Repository)
TUR is described as the Termux equivalent of the Arch User Repository idea: users install pre-compiled packages instead of building on-device. Packages live under tur/<your-package-name>/build.sh (not packages/), and you build with the Termux build scripts:
TERMUX_INSTALL_DEPS=true ./build-package.sh -a <arch> <package-name>
Two things to remember:
- TUR packages are not official Termux packages. Don't ask the core Termux team for support on them.
- TUR has a curated contributor workflow, so expect review.
Option 3: Host your own APT repository
If you want full control, you can build .deb packages and host them as an APT repository (for example on GitHub Pages). Users add your repository, then install with pkg or apt.
Pros: your release schedule, your rules.
Cons: you handle signing, hosting, architecture builds (aarch64, arm, x86_64, i686), and user trust. Every user has to add your repo first.
This is the most work, but it's the right call for larger projects with their own ecosystem.
Option 4: Termux App Store (community package layer)
Termux App Store is a community-driven TUI and CLI package manager for Termux. Think of it as an AUR-like layer for tools that are too niche, too experimental, or too fast-moving for the official repository.
Packages are described by a build.sh file. Users can install a pre-built .deb (fast path, SHA256-verified) or force a source build.
Step 1: Get the tooling
git clone https://github.com/djunekz/termux-app-store
cd termux-app-store
Step 2: Create your build.sh
Every package is just one file: packages/<tool-name>/build.sh. It tells Termux App Store what your tool is, where to download it, and how to install it.
You don't have to write it by hand. Pick whichever of these three ways fits you:
| Way | Best for | Command |
|---|---|---|
A. pkg-scaffold.py (wizard) |
Beginners. It asks questions and writes the file for you | python pkg-scaffold.py |
B. termux-build |
People who want a template or a one-line generator | ./termux-build init <github-url> |
| C. Manual | People who already know the format | Copy template/build.sh and edit |
Way A: the scaffold wizard (easiest)
Run it from inside the cloned repo:
python pkg-scaffold.py
Or give it your GitHub URL up front so it can pre-fill everything:
python pkg-scaffold.py --from https://github.com/yourname/my-awesome-cli
The wizard walks you through a few steps:
- Source repository (optional). Paste your GitHub URL and it fetches the description, license, and latest release or tag automatically.
- Package info: name (lowercase and hyphens only), description, homepage, license, maintainer, version.
- SHA256. It can download your source and compute the checksum for you.
- Build method. It scans your repo and detects whether it's a Python script, pip package, shell script, npm, Cargo (Rust), Go, Makefile, CMake, and more.
- Entrypoint (for script-type tools) and any extra dependencies.
-
Review, then confirm, and it writes
packages/my-awesome-cli/build.sh.
If you don't give it a GitHub URL, it just asks you to type everything in manually.
Way B: termux-build
Generate a blank template:
./termux-build create my-awesome-cli
Or auto-create from a GitHub repository:
./termux-build init https://github.com/yourname/my-awesome-cli
Both give you packages/my-awesome-cli/build.sh. Note that termux-build is mainly a creation and validation helper. It is not an auto-publish tool, so nothing gets uploaded until you open a pull request yourself.
Step 3: Check the metadata (and fix anything the tools missed)
Whichever way you used, open the generated file and make sure it looks right. A package definition carries metadata like this:
TERMUX_PKG_HOMEPAGE="https://github.com/yourname/my-awesome-cli"
TERMUX_PKG_DESCRIPTION="One-line description of what the tool does"
TERMUX_PKG_LICENSE="MIT"
TERMUX_PKG_MAINTAINER="@yourname"
TERMUX_PKG_VERSION="1.0.0"
TERMUX_PKG_SRCURL="https://github.com/yourname/my-awesome-cli/archive/refs/tags/v${TERMUX_PKG_VERSION}.tar.gz"
TERMUX_PKG_SHA256="<sha256 of the source tarball>"
Get the checksum with:
curl -L <your-source-url> | sha256sum
The exact required fields can evolve, so run
./termux-build guideand./termux-build templatefor the current format.
Step 4: Validate before you submit
./termux-build lint my-awesome-cli # check the package
./termux-build check-pr my-awesome-cli # check it's ready for a pull request
./termux-build doctor # diagnose your environment
Step 5: Open a pull request
Push your branch and open a PR with your packages/my-awesome-cli/ directory. After it's merged, users can find and install it:
pip install termux-app-store
termux-app-store search my-awesome-cli
termux-app-store install my-awesome-cli
Prefer to compile locally? Users can force a source build with termux-app-store fix-install my-awesome-cli.
The whole flow in 4 commands
git clone https://github.com/djunekz/termux-app-store && cd termux-app-store
python pkg-scaffold.py --from https://github.com/yourname/my-awesome-cli # 1. generate build.sh
./termux-build lint my-awesome-cli # 2. validate it
./termux-build check-pr my-awesome-cli # 3. check PR readiness
# 4. commit packages/my-awesome-cli/ and open a Pull Request
Trade-off to be aware of: because this is an independent community layer, it is not the official Termux repository and packages aren't installed through plain pkg install. In exchange you get a much lower barrier to entry.
Option 5: GitHub releases plus an install script
The fastest way to ship: publish release binaries or a script on GitHub and document a one-liner.
pkg install git
git clone https://github.com/yourname/my-awesome-cli
cd my-awesome-cli && ./install.sh
It works, but there is no update mechanism, no checksum verification by default, and users have to trust and read your script. Fine for early versions; plan to graduate to one of the options above.
Checklist before you distribute anywhere
- [x] A clear license file
- [x] Tagged releases with a stable source URL
- [x] A SHA256 checksum for every release artifact
- [x] Tested on at least aarch64, ideally also
armandx86_64 - [x] Declared dependencies (
pkg install ...) - [x] No hardcoded
/usr/bin. Termux uses$PREFIX(/data/data/com.termux/files/usr) - [x] A README with a copy-pasteable install command
- [x] No telemetry or surprising network calls without disclosure
FAQ
Why was my package rejected from termux-packages?
Usually scope, maintenance burden, or build reproducibility. Read the contributing guide, check for existing packages, and consider TUR or a community layer instead.
What's the difference between termux-packages and TUR?
termux-packages is the official, core-maintained repository. TUR is a separate user repository with its own curated workflow, and its packages are not official Termux packages.
Can I distribute a Termux package without asking anyone's permission?
Yes. Host your own APT repository or release .deb files yourself. You trade review for responsibility.
How do I make a .deb for Termux?
Use the Termux build system (build-package.sh with a build.sh) so paths and prefixes are correct for Termux rather than a standard Linux distro.
Which architectures should I support?
Termux runs on aarch64, arm, x86_64, and i686. aarch64 covers most modern phones.
Wrapping up
There's no single "right" place to publish a Termux tool. Use the official repo for stable, broadly useful software, TUR for curated extras, your own APT repo when you want total control, and a community layer like Termux App Store when your tool is niche or moving fast.
Whichever you choose, ship checksums, document the install command, and test on more than one architecture. Your users will thank you.
If you've got a Termux tool you want more people to use, packaging it is the highest-leverage thing you can do. Questions or war stories about getting packages rejected? Drop them in the comments.
Links
- Termux App Store: https://github.com/djunekz/termux-app-store
- Termux packages (official): https://github.com/termux/termux-packages
- TUR: https://github.com/termux-user-repository/tur
Top comments (0)