Project
MAR 2026

Pavan Dhadge

Redmi 8A Homelab - Termux SSH Portfolio Server

Old Phone → Tiny Always-On Linux Node

This project started with one simple rule: old hardware should not be thrown away.

I took a 2020 Redmi 8A Dual (Snapdragon 439, 2GB RAM, 32GB storage) that was sitting idle after I upgraded phones, installed Termux, set up SSH, and turned it into a lightweight, always-plugged-in homelab node.

It became my daily driver for remote shell access, secure portfolio serving via SSH tunnels, file sync, script testing, and basic infra experiments — all without spending a rupee on new hardware.


View Homelab Setup on GitHub →

Why This Setup?

I wanted hands-on systems practice — SSH discipline, port forwarding, process management, backups — without buying a Raspberry Pi or VPS.

This tiny phone taught me more about real Linux operations than many cloud tutorials:

  • Keeping services alive on 2GB RAM
  • Why tunneling beats exposing ports
  • How to script automation when CPU/thermal limits bite
  • That meaningful infra learning doesn’t require racks or $200 boards

It proved: you can run a legitimate homelab node on hardware most people discard.

Core Setup Flow (Step-by-Step)

1. Install Termux

  • Download from F-Droid (Play Store version is outdated and limited — avoid it)
  • Grant storage permission on first launch

2. Update & install essentials

pkg update && pkg upgrade -y
pkg install openssh python git neovim rsync procps-ng termux-api

3. Set SSH password & start server

passwd   # set a strong password
sshd     # starts on port 8022

4. Find phone IP
Settings → Wi-Fi → current network → IP address (e.g., 192.168.1.105)

5. SSH in from laptop

ssh -p 8022 pavan@192.168.1.105

6. Serve portfolio securely via SSH tunnel (most common workflow)

# On phone (in Termux)
cd ~/portfolio
python -m http.server 8000
# On laptop (background tunnel)
ssh -L 8080:localhost:8000 pavan@phone-ip -p 8022 -N -f

# Now open http://localhost:8080 — content served from phone, encrypted via SSH

Auto-start on boot (optional but recommended):

Create ~/.termux/boot/start-services.sh:

#!/data/data/com.termux/files/usr/bin/sh
termux-wake-lock
sshd

Make executable: chmod +x ~/.termux/boot/start-services.sh

Extensions & Hardening I Added

  • Daily rsync backups to laptop:
# On laptop cron
rsync -avz --delete -e "ssh -p 8022" pavan@phone-ip:~/portfolio/ ~/backups/phone-portfolio/
  • Restart script for sshd + server:
# ~/restart-services.sh
pkill sshd
pkill python
sshd
cd ~/portfolio && nohup python -m http.server 8000 &
  • Monitoring aliases:
alias health='top -n 1 -b | head -15 && echo "SSHD running: $(pgrep sshd)"'
alias lag='netstat -tuln | grep 8022'
  • Battery/thermal discipline — disable battery optimization for Termux in Android settings, keep phone cool/plugged in
  • Fail2ban lite — simple script to block repeated failed SSH attempts (optional)

Constraints & Tradeoffs

  • 2 GB RAM → limit to 1–2 concurrent tasks; no Docker
  • Thermal throttling → avoid CPU-intensive compiles; good ventilation or cooling pad helps
  • Android kills → battery optimization can kill Termux — disable it + use wake-lock
  • Not production → fine for personal use, learning, light serving (portfolio, notes, scripts)

But for remote shell, file access, and systems experiments? It punches way above its weight.

Outcome & Reflection

This setup became my daily remote terminal — quick script tests, portfolio updates, note sync, even light homelab monitoring — all on free hardware.

It reinforced a mindset I carry everywhere now:

Optimize what you have. Instrument what you run. Learn by operating real (even tiny) systems.

No cloud abstractions. No vendor dashboards.
Just a phone, Termux, SSH, and a terminal — debugging why sshd died at 3 a.m. or why rsync hung on a symlink.

Repository: github.com/pavandhadge/redmi-8a-termux-ssh-portfolio

If you have an old Android phone, give it a second life.
The learning ROI is ridiculous.

Setup tips, bugs, or war stories?
DM @pavan_dhadge or open an issue.

“This homelab taught me that meaningful infrastructure doesn’t need to be expensive — it just needs to be real, operated, and broken a few times.”