After My Laptops Were Stolen, I Learned to Build From Android

The work did not disappear with the hardware

Having laptops stolen was disruptive in the ordinary, unglamorous ways theft usually is: a real financial hit, and the sudden loss of the specific machine my development environment had been built on top of. Local files, installed tools, saved SSH sessions, half-finished edits—all of it had quietly become tied to one physical device, in ways I hadn't examined until the device was gone.

What didn't stop was the work itself. Websites still needed maintenance. A VPS was still running live applications. Projects still had deadlines and users. None of that paused because my laptop had. I still had an Android phone, a data connection, and accounts I could log back into—so that became the starting point, not because it was ideal, but because it was what was left.

The thefts were not a gift. They were losses. But they exposed how dependent my workflow had become on a specific piece of hardware.

I want to be direct about that distinction, because it's easy to romanticize a hard period after the fact. Nothing about losing laptops made me a better developer by itself. What it did was force a question I hadn't had to answer before: if my workflow only worked on one machine, what exactly did I actually own—the work, or the device it happened to live on?

Discovering Termux

I did not discover Termux because I wanted to prove that a phone could replace a laptop. I discovered it because the laptops were gone and the work still existed.

Termux ↗ is a terminal emulator and Linux-style environment for Android that runs without rooting the phone. It is not a complete conventional Linux distribution running underneath Android, and it does not grant root access to the device—it's a sandboxed userland with its own package manager, running on top of Android's normal app permissions. That distinction mattered to me early on, because it meant I could use it without turning phone security into a separate project of its own.

What Termux actually provides, out of the box or through its package manager, is a working shell and a real set of development tools:

• A proper shell (bash, with others available)
• A package manager for installing and updating tools
• Git
• OpenSSH, for both connecting out and, if needed, accepting connections
• Python
• Node.js
• curl
• rsync
• nano and Vim
• The common command-line utilities most shell work assumes are just there

Before this, my phone was mostly a device for checking dashboards and reading notifications—useful for looking at things, not for doing things. Termux changed that. It turned the phone into something that could execute commands, manage files, work with a Git repository, and reach a remote system over SSH. That's a different category of device than a phone that just renders a mobile website well.

The phone became the terminal; the VPS did the heavy work

The architecture that emerged was simple, and it stayed simple on purpose: Android phone → Termux → SSH → VPS. The phone supplied the screen, the keyboard, and a secure connection out. The VPS supplied the actual Linux server, the processing power, the application environment, and persistent storage. Termux was the bridge between them, not a replacement for either end.

In practice, that meant using Termux for a fairly narrow, specific set of jobs:

• Opening SSH connections to the VPS, authenticated with keys rather than passwords
• Editing files directly on the server for small, urgent fixes
• Reading application and server logs when something needed attention
• Restarting a stalled service or application process
• Checking whether a deployment had actually gone out cleanly
• Transferring files where that was the right tool for the job
• Running Git commands against a repository, on the phone or on the server
• Checking on databases and web applications running on the VPS

I'm intentionally not publishing real server addresses, usernames, key fingerprints, ports, tokens, or internal paths here—those are infrastructure details, not something a reader needs to see the pattern explained. The pattern itself is what mattered: keep the heavy, stateful work on a server that's always on, and use the phone as a thin, secure way to reach it.

The command line stopped feeling abstract

With no room for a dozen windows and graphical dashboards, I had to understand what each command was actually doing.

A small screen makes most graphical tooling impractical. There's no comfortable room for a file manager, a log viewer, a database GUI, and an editor open side by side. That constraint pushed nearly everything toward the command line—not as a stylistic choice, but because it was genuinely the clearest way to get anything done on that screen.

Working that way, consistently, filled in gaps I hadn't noticed I had. I came away with a much more concrete understanding of:

• Navigating with paths and directories instead of clicking through folders
• Creating and editing files directly, without a GUI editor to lean on
• Permissions and ownership, and what actually breaks when they're wrong
• Processes and services—what's running, and what depends on it staying running
• Environment variables and how configuration actually reaches a program
• Installing packages and managing what a project depends on
• Network connections—what's listening, what's reachable, and from where
• Reading logs directly instead of watching them scroll past in a dashboard
• Pipes, redirects, and actually reading command output instead of skimming a summary
• Automating repetitive steps with small scripts instead of repeating them by hand
• The difference between the remote filesystem on the VPS and whatever local storage the phone had

None of these are exotic concepts. What changed is that I could no longer treat them as background details a graphical tool handled for me. On a phone, over SSH, each command was the whole interface—so I had to actually understand what it did.

tmux made remote work survivable

Mobile connections drop. Android can suspend background apps to save battery. SSH sessions disconnect for reasons that have nothing to do with the work happening inside them. On a laptop with a stable connection, that's an occasional annoyance. On a phone, moving between Wi-Fi and mobile data, it was a near-constant risk to anything left running in a plain SSH session.

tmux ↗ solved the specific problem that caused: it runs the session on the VPS itself, not on the phone, so a dropped connection doesn't kill whatever was running. Reconnecting and reattaching to the same tmux session picks up exactly where the connection left off—the command that was running, the scrollback, the working directory, all still there.

That's a meaningful reliability improvement for interactive work, and it's worth being precise about what it is not. tmux doesn't prevent a process from crashing, and it isn't a substitute for a real service manager on anything meant to run unattended in production. An interactive tmux session is something a person is actively working in and can reattach to; a production service manager is what should actually be responsible for restarting a crashed application, independent of whether anyone's phone is connected at all. I used tmux for the first kind of problem, not as a stand-in for the second.

Git finally made sense

I already knew GitHub existed before any of this. What changed was that working across a phone, a remote VPS, and eventually replacement devices made version control something I actually needed, not a best practice I was choosing to follow.

It's worth being precise about the two pieces, because they get conflated constantly: Git is the distributed version-control system itself—the tool that tracks changes to files and lets you move between versions of a project. GitHub is a service that hosts Git repositories and adds collaboration on top: issues, pull requests, access control, and a copy of the repository that lives somewhere other than any one machine.

Working from Termux over SSH, the actual workflow settled into a fairly consistent sequence:

1. Clone or pull the repository
2. Check the repository status
3. Create or use a working branch
4. Make focused changes
5. Review the diff
6. Stage the intended files
7. Commit with a meaningful message
8. Push the commit to GitHub
9. Review or merge it
10. Deploy from that controlled repository state

Over time that settled into branches like main, staging, and feature/<name> for me specifically—not because that's the only correct Git model, but because it's the shape that fit how I was actually moving work between a phone, a server, and, eventually, new devices. Other workflows fit other situations better.

GitHub became more than online storage

Before this, GitHub was mostly a place I uploaded finished code. Afterward, it became something closer to infrastructure for how I actually worked:

• An off-device copy of everything I'd actually committed and pushed
• A visible history of a project, not just its current state
• A record of decisions, in commit messages and pull requests, not just memory
• The way I moved work between the phone, the VPS, and whatever device I picked up next
• A deployment source—pulling a known, controlled state rather than whatever happened to be on a disk
• A collaboration and review layer, when other people or tools needed to see the same code
• A recovery point for anything that had actually been pushed

GitHub only protects work that has actually been committed and pushed. An untracked file on a stolen laptop is still an untracked file on a stolen laptop.

That qualification matters more than it sounds. GitHub is not a replacement for database backups, uploaded user files, server configuration backups, encrypted secret storage, or full device backups. It protects source code that made it into a commit and a push—nothing that stayed local, and nothing that isn't source code in the first place.

A practical mobile workflow

Reduced to its parts, the workflow that emerged looked like this:

A representative session, with any real hostnames or paths replaced by placeholders, looked roughly like ssh user@your-server, then tmux attach or tmux new, then the ordinary Git sequence from inside that session. Nothing about it was exotic—the value was in how consistently it held up under a dropped connection or a suspended app.

What working from a phone could—and couldn't—do

None of this makes a phone equivalent to a laptop, and I don't want to suggest otherwise. Working this way, consistently, meant working around real limitations:

• A small screen, even with a terminal font tuned down
• A touchscreen keyboard, which is slower and more error-prone than physical keys for anything long
• Selecting and copying text is genuinely harder than it is with a mouse
• Android's storage boundaries, which restrict what an app can read or write without extra steps
• Background-process restrictions that can suspend a long-running task without warning
• Connection interruptions moving between Wi-Fi and mobile data
• Copying long terminal output somewhere useful is more friction than it should be
• Limited multitasking compared to several windows on a real desktop
• Slower visual debugging—there's no comfortable side-by-side browser and DevTools view
• Real fatigue during long sessions, from the screen size and the typing method alone

Termux gave me continuity and real capability when a laptop wasn't an option. It did not make a laptop unnecessary. A full workstation is still the better tool for most development work—Termux is what let the work keep moving when that wasn't available.

What device loss taught me about security

Losing hardware you don't control anymore is a specific kind of security event, separate from the inconvenience of not having the device. The general lessons that experience reinforces are ones I now treat as standard practice rather than optional cleanup:

• Revoke SSH keys that were issued to or stored on lost hardware
• Revoke any access tokens that could have been exposed on that device
• Sign out active sessions tied to accounts the device had access to
• Rotate passwords where there's any reasonable doubt
• Use device encryption and a strong screen lock on every device going forward
• Enable two-factor authentication or passkeys wherever it's supported
• Keep recovery codes stored somewhere separate from the devices they'd be recovering
• Never commit secrets to a repository, regardless of whether it's private
• Use separate keys for separate devices, so one key's exposure doesn't touch everything
• Maintain backups that are independent of any single device or account

GitHub's own guidance ↗ is direct about this: if a device with access to your account is lost or stolen, you should revoke its SSH keys and tokens and review which credentials had access. That's not an edge case in their documentation—it's the expected response to exactly this situation.

The more resilient system I use now

What came out of this wasn't a permanent commitment to developing on a phone. It was a workflow where no single device is a single point of failure:

• GitHub holds the controlled source history
• The VPS runs the deployed applications, independent of any one client device
• A laptop is the primary workstation when one is available
• Android and Termux remain a legitimate fallback, not a novelty
• SSH keys are issued and revoked per device, not shared across all of them
• No single device is allowed to hold the only copy of anything that matters

Using Git and GitHub as an actual cross-device workflow—not just a place to push finished code—is what made the concepts stick in a way reading about them never did. I understand branching, history, and remotes differently now because I depended on them working correctly from a phone, over an unreliable connection, with real work on the other end.

Conclusion

Having laptops stolen did not make development easier. It forced me to separate the work from the device. Termux gave me a command line, SSH gave me access to the server, and GitHub gave the code a history and a home that did not disappear with one piece of hardware.

That separation is still how I work today, laptop or not. I can pick up Android, Linux, or Windows, reach the same VPS, and pull the same repositories from GitHub, because the work was never really tied to one machine in the first place—it just took losing one to see that clearly. That's also the same discipline behind how I approach running my own VPS infrastructure: build the parts that matter so they don't depend on any single piece of hardware to keep working.