ternux /docs/pro
A professional tool does not merely finish. It proves the result and leaves a safe next step.
— Sobuj Miah

ternux Pro

A guided deployment with private, version-matched fixes—not a public pile of commands.

Status: private alpha — not yet on sale. The installer exists in a private repository, but the storefront, live licence endpoint, complete acceptance testing and customer documentation are not ready. There is no official public install command today.

ternux Pro is being built for people who want a repeatable GPU-accelerated Debian/Xfce4 workstation without manually coordinating Termux, PRoot, Termux:X11, Mesa, audio and Android process limits.


Honest implementation status

Implemented in the private alpha

Release blockers

These are launch gates, not small-print promises. Public wording will change only when the corresponding private test passes.


Capability model

Capability Private-alpha reality
Device preflight Implemented; blocks unsupported Android/architecture and insufficient base storage
GPU-aware plan Implemented; Adreno uses the Turnip route when available, other GPUs use VirGL
Recorded resume Implemented; completed modules are stored and skipped on resume
Targeted doctor repair Implemented; failed checks map to the responsible module
Transactional rollback Release blocker; not yet implemented
Static verification Implemented for key files, services and launcher state
Live renderer acceptance Explicit alpha command exists; real-device Zink/VirGL validation is a release blocker
Private recovery runbook Drafted; version binding and device validation still required
Secure paid delivery Test implementation exists; production deployment and privacy review remain

Why fixes stay private

Public documentation explains compatibility, architecture, responsible use and what evidence identifies a failed boundary. Exact repair commands, module reruns, Android-version actions, rollback decisions and recovery sequences are private because they must match a specific installer and Mesa release.

Publishing an old fix as a timeless command is unsafe. A Pro customer should get the recovery procedure tested against the exact toolkit version they received, plus a support bundle that identifies state without exposing credentials.

See Support & diagnostics for the public symptom map and safe report format.


Workload profiles

Desktop and development

A Debian/Xfce4 workspace with Git, build tools, Node.js and terminal-based coding assistants. Third-party agents retain their own provider, account and licence requirements; ternux does not make them permanently free.

Local AI

A Vulkan-enabled llama.cpp option for compact GGUF models. A 1–2B Q4 model with a conservative context is the practical starting point on many phones. RAM, thermals, model architecture and SoC still determine performance.

Creative / Blender

The private creative option includes Blender and selected media tools. It is positioned for low-poly modelling, simple materials, modest scenes and short viewport sessions. On the author’s tested Turnip-enabled device, lightweight Blender work was smooth enough to be useful. This remains an observed result, not a cross-device promise of production rendering or simulation performance.

Authorised security lab

The current alpha includes basic network diagnostics; a broader defensive lab profile is still planned. Any security tooling is for systems the customer owns or has explicit permission to test. Android/PRoot cannot promise monitor mode, packet injection, arbitrary kernel access or unrestricted USB integration.


Private documentation set

The version-matched Pro package is planned to include:

  1. Quickstart — access, artifact integrity, preflight and supported launch.
  2. Operator guide — start/stop, status, workload profiles, updates and safe storage.
  3. Verification handbook — static checks, first-session renderer acceptance, audio and baseline evidence.
  4. Recovery runbook — targeted module repair, backup/restore and rebuild decision rules.
  5. Workload guides — Blender, local AI, development agents and authorised network/security use.
  6. Release notes — supported device combinations, known limitations and migrations.

These documents and repair details live in the private Pro repository. An obscure URL or noindex page in the public repository would not make them private.


After installation

A release-quality handover will require:

  1. Save the status report and toolkit version.
  2. Launch once and prove the actual renderer; do not accept llvmpipe.
  3. Test audio, shared storage and a clean second launch.
  4. Add one optional workload at a time.
  5. Record a short performance, memory and thermal baseline.
  6. Create a known-good backup before experiments.
  7. Use version-matched updates and private recovery instructions.

The public Get ternux page contains readiness and next-step planning without revealing the deployment or repair implementation.


What Pro cannot promise


Requirements

Android 10+, aarch64, at least 12 GB free, a maintained Termux build and Termux:X11. Four GB RAM is the practical floor; 6–8 GB is more comfortable. Adreno offers the preferred acceleration route, while other GPUs use VirGL.


Release gates

Gate Required evidence
Installer hardening Core failure handling, archive safety and update tests pass
Renderer acceptance First launch records Zink/Turnip or VirGL and rejects llvmpipe
Recovery Resume, targeted repair, backup/restore and declared rollback behaviour are tested
Device matrix Supported and known-limited devices have recorded renderer evidence
Secure delivery Licence flow, artifact integrity, privacy and seat handling pass review
Documentation freeze Customer docs match the exact release artifact
Public launch Storefront, support route, release notes and stable endpoint are live

No launch date or price is announced. An endpoint shown anywhere other than the official release channel should be treated as untrusted.


ternux Pro — Copyright (c) 2026 Sobuj Miah (@soobujmiah). All rights reserved.

Edit this page on GitHub → ↑ Back to top