Get ternux

ternux turns a supported Android phone into a Debian Xfce4 workstation with a GPU-backed graphics path, without rooting the device.

Current availability: ternux Pro is in private development and is not yet for sale. There is no public installer endpoint today. Watch the GitHub repository for beta and launch announcements.

This public page is a readiness and next-steps guide. The complete installer, implementation procedure, recovery runbook and Pro operator documentation are private release materials; they are not published on GitHub Pages.

Is your device a good fit?

The abandoned Play Store build of Termux is not supported. Device-specific OEM power management may also affect long-running desktop processes.

Record a compatibility profile

These checks do not install or modify anything. Save the output for a future beta report or support request:

uname -m
getprop ro.product.manufacturer
getprop ro.product.model
getprop ro.build.version.release
df -h "$HOME"
ls -l /dev/kgsl-3d0 2>&1

/dev/kgsl-3d0 normally indicates an Adreno device and therefore the preferred Turnip path. A missing node does not automatically mean the desktop is unsupported; it means the compatible VirGL path is more likely.

What the private installer handles

The Pro workflow is designed as nine verified phases rather than one opaque script:

1. Preflight — architecture, Android version, storage, network and app checks.
2. Termux foundation — required repositories and host-side services.
3. Debian workspace — container, desktop and non-root user.
4. Graphics selection — Adreno/Turnip or the compatible VirGL route.
5. Desktop integration — display, audio, locale, fonts and shared storage.
6. Reliable launch controls — start, stop, recovery and shell shortcuts.
7. Android safeguards — detection of background-process restrictions.
8. Verification — renderer, Vulkan, display and audio health checks.
9. Handover — status report, workload choices, backup and maintenance notes.

Each phase must verify itself before the next starts. The design is resumable, and a failed phase should clean up its own partial changes.

Prepare now

1. Back up important phone data. ternux does not repartition the phone, but a backup is still the right starting point for any large environment change.
2. Use official app sources. Install current Termux and Termux:X11 only from their maintained F-Droid or GitHub release channels.
3. Reserve storage. Keep at least 12 GB free for the base system. Local AI models, Blender assets and security datasets need additional space.
4. Plan for power and heat. Keep the device charged, remove a heat-trapping case when appropriate and avoid covering the phone during sustained work.
5. Choose the first workload. Desktop productivity, lightweight Blender, local AI, development tooling and an authorised security lab have different storage and thermal profiles.
6. Watch the repository. Beta access, supported-device notes and the real release channel will be announced there—not through an unofficial script or copied download link.

After setup: the next-doing guide

Once the private installer reports success, follow this order:

1. Verify before customising

Run the Pro status and doctor checks, then confirm that the desktop reports Zink/Turnip or VirGL, not llvmpipe. Save the generated system report. That clean baseline makes later troubleshooting much faster.

2. Establish a normal start and stop routine

Launch the desktop once, test audio and shared storage, then shut it down using the provided clean-stop command. See Usage for daily controls.

3. Add only one workload profile at a time

Start with the profile you actually need:

• Creative: lightweight Blender modelling and simple scenes.
• Local AI: Vulkan-enabled llama.cpp and phone-sized quantised models.
• Development: Git, Node.js tooling and terminal-based coding assistants.
• Security lab: network analysis and auditing tools for systems you own or are explicitly authorised to test.

Verify the desktop after each profile so any regression has a clear cause.

4. Capture a performance baseline

Record the renderer string, a short graphics benchmark, idle memory and device temperature. Scores vary by SoC, Android build, Mesa version and cooling, so a personal baseline is more useful than somebody else’s number.

5. Back up the working state

Create the first container backup before adding large models, experimental packages or project data. Keep valuable source files in shared storage or a remote Git repository as well.

6. Update deliberately

Use the Pro update channel and read its release notes. Do not replace held Mesa components casually; a routine package upgrade can change the graphics path.

Safe delivery rules

• The official installer will be distributed only through the release channel named on this site and the repository.
• Never paste a licence key, API key, model-provider token or private support bundle into a public issue.
• Do not run copied curl | bash commands that claim to be ternux Pro.
• Keep local model servers bound to loopback unless you add authentication and intentionally design network access.

Already running ternux?

Continue with Usage, review Configuration, or use Support & diagnostics to classify an unhealthy renderer, audio path or desktop session.

ternux — Copyright (c) 2026 Sobuj Miah (@soobujmiah) · MIT