JuiceSSH Was Removed from the Play Store: What Happened and What to Do Now

The short answer {#short-answer}

JuiceSSH was unpublished from the Google Play Store in December 2025. It wasn’t banned for anything it did — it was removed for what it stopped doing. The app’s last release was 4 February 2021, and Google Play requires apps to keep targeting a recent Android API level to stay listed. Four years of silence made that impossible.

If you already have it installed, it probably still opens. That is not the same as being fine:

• No new installs. New phone, factory reset, or a colleague who wants the same setup — the listing isn’t there.
• The Pro licence check has broken for many users. Reports since December 2025 describe purchases made before that date no longer being recognised, with support unresponsive.
• No security patches, ever again. This is an app holding the private keys to your servers.

The practical move is not “find a way to keep JuiceSSH running.” It’s rotate your keys and move to a maintained client — and this article covers how to do that without locking yourself out of a box you can only reach from your phone.

What actually happened {#what-happened}

Here’s the timeline as it can be reconstructed from public sources.

The specific unpublish date of 11 December 2025 comes from AppBrain, a third-party Play Store tracker, rather than from Sonelli or Google — neither has issued a statement.

What makes this sting more than a typical app death is the scale. JuiceSSH had been on the store for 13 years, accumulated millions of downloads, and sat at roughly 4.1 stars across ~52,000 ratings. For a large chunk of Android sysadmins it was the SSH client — the one you installed without thinking about it in 2015 and never revisited.

There is no evidence of anything malicious here. Both founders reportedly moved on to jobs elsewhere in the industry, and the app was left to run on autopilot until the autopilot ran out. The unsatisfying part, and the thing the Hacker News thread is genuinely angry about, is the absence of a clean wind-down: no final release with Pro unlocked, no refunds, no source release, no goodbye post.

Why Google pulled it {#why}

This part is worth understanding, because it will happen to other apps you rely on.

Google Play enforces a target API level requirement. To stay fully listed, an app must target an Android API level within two years of the latest major Android release. Apps that fall behind get progressively restricted:

1. First, invisibility. The app stops appearing in Play search and browse for users on newer Android versions. Existing users keep it; new users can’t find it.
2. Then, unavailability. New installs are blocked outright.
3. Eventually, unpublishing. The listing comes down.

An app last built in early 2021 targets around Android 10/11-era APIs. By late 2025, with Android 15 and 16 shipped, that’s roughly five API levels behind a two-year window. There was no discretionary decision to make.

The requirement gets criticised — it does kill perfectly functional small apps whose developers moved on — but the reasoning is straightforward. Newer API levels are how Android enforces scoped storage, stricter background limits, runtime permission changes, and hardware-backed keystore behaviour. An app frozen at API 29 opts out of five years of platform security work by definition.

For an SSH client, that’s not an abstraction. The app is storing private keys and passwords on a device you carry around and occasionally leave in an airport. It’s also shipping its own crypto and SSH implementation — libraries that have had CVEs and fixes since 2021 which a frozen binary simply never received.

Does my install still work? {#still-works}

Mostly, with important caveats.

Removing a listing doesn’t uninstall the app. Android leaves installed apps alone when a Play listing is unpublished. Opening JuiceSSH, connecting to a saved host, and running commands should still work.

What breaks is anything that phones home. The Pro licence validation is the reported casualty (next section). Anything else that depends on Sonelli infrastructure should be assumed to be on borrowed time.

Reinstalling is unreliable. Play normally keeps unpublished apps visible in your library under “My apps” so you can reinstall something you previously had, and several users report this still working for JuiceSSH. But that’s Play’s general behaviour, not a commitment, and it doesn’t survive a switch to a new Google account.

The end date is unknown but real. Every Android release tightens something. A frozen 2021 app runs until a platform change breaks it — an API removal, a permission model change, a page-size or ABI requirement — and when that happens there is nobody to ship a fix. You don’t get a warning; you get an app that stops opening on the morning you need it.

That’s the actual risk profile. It’s not “JuiceSSH is broken today.” It’s “JuiceSSH will break on a day you don’t choose, and your servers are on the other side of it.”

The Pro licence problem {#pro-licence}

Running alongside the removal, and easy to confuse with it, is a separate failure: JuiceSSH Pro unlocks stopped being recognised.

What users have reported publicly since December 2025:

• Purchases made before December 2025 no longer validate — the app reverts to the free feature set.
• Users attempting to repurchase report that the Pro price is higher than what they originally paid. We have not been able to verify the current figure against an official price page, so treat whatever the store shows as authoritative rather than any number quoted in forum threads.
• Support does not respond. This is consistent with the pattern going back years.

The most credible reading in the public discussion is not that this is an exit scam. It’s infrastructure rot: a licence-validation service that has been running unattended for years and has now degraded — an expired certificate, a deprecated Play Billing API, a dead endpoint — with nobody left to notice. The effect on you is the same either way.

The thread also contains detailed instructions for decompiling the APK and patching the licence check to always return true. Legality aside, think about what that actually asks you to do: install a self-signed, community-modified binary from an unverified source, and give it your production SSH private keys. That’s a worse security position than the one you’re trying to escape, in exchange for keeping a dead app on life support.

If you paid for Pro and lost it, the realistic paths are a Google Play refund request (long odds on a years-old purchase, but it costs a support ticket) and moving to something maintained. Not a patched APK.

Should I sideload the APK? {#sideload}

No — and the reasoning is specific to what this app is, not general sideloading caution.

APK mirrors still host JuiceSSH 3.2.2. Installing from one means:

• A 2021 binary with 2021 dependencies. Every SSH, TLS, and crypto fix from the last five years is absent.
• No integrity guarantee. Play’s signature verification is what stopped anyone from serving you a modified build. On a mirror, you’re trusting the mirror.
• The blast radius is your infrastructure. A compromised SSH client doesn’t leak photos. It leaks the keys to every host you’ve saved, and it can read every command and every credential you type into a session.

An SSH client is close to the worst possible category of app to sideload from an unofficial source. If you install one app only from official stores, make it this one.

The one narrow exception: if you’re locked out of a server that only accepts a key trapped in JuiceSSH, and you have no console access, then keeping an existing install alive long enough to regain access is a legitimate emergency measure. That’s a recovery step with a deadline, not a plan.

Migrating off JuiceSSH safely {#migrate}

The trap here is getting halfway through a migration and finding yourself locked out of a VPS you can only reach from a phone. Do it in this order.

1. Inventory what’s in there. Open JuiceSSH and write down every connection: hostname or IP, port, username, auth method, and which jump host or port-knock it needs. Do this while the app definitely still opens.

2. Set up the new client first — don’t uninstall anything. Install your replacement and get it working alongside JuiceSSH. Two SSH clients on one phone is fine.

3. Generate new keys on the new client; don’t try to export the old ones. JuiceSSH stores identities in its own encrypted database and doesn’t offer a clean private-key export, and this is one case where the awkward path is also the right one. Generating fresh keys means:

• You get ed25519 keys instead of whatever RSA key you made in 2016. (If you want the reasoning, ed25519 vs RSA covers it.)
• The key material never leaves the new app, so there’s no plaintext key sitting in a clipboard or a note.
• Any key that spent years in an unmaintained app gets retired, which it should be regardless.

4. Add the new public key before removing the old one. For each host, append the new public key to ~/.ssh/authorized_keys while your old JuiceSSH access still works. ssh-copy-id from an existing session is the fast way; copying an SSH key to a server walks it through.

5. Verify the new key works — from the new app, on a fresh connection. Not a cached session. Close and reopen.

6. Only then, revoke the old key. Remove the old public key line from authorized_keys on every host. Any key you can’t confidently account for should come out too.

7. Now uninstall JuiceSSH.

If a host has console access through your provider (a DigitalOcean/Hetzner/OVH web console, a Proxmox shell, an IPMI), confirm you can get into it before step 6. That console is your undo button.

Finally, if you were relying on the JuiceSSH plugin ecosystem — the Tasker plugin, PortKnocker, the performance monitor — those are separate apps with their own listings. We haven’t verified the current status of each, so check the store page and last-update date for any plugin you depend on before assuming it will keep working, and plan replacements for the ones that look equally dormant.

Where to go instead {#alternatives}

The honest field, with what each one is actually for:

TermAI is the closest match to what JuiceSSH was for: open the app, tap a saved host, be in a shell in two seconds. Where it differs is the two things a 2021 codebase was never going to have — Tailscale built in, so you reach a home server or a firewalled VPS without exposing port 22 or juggling a second VPN app, and an AI assistant that suggests commands you confirm before running. That second part matters specifically on a phone: the free tier is 5 AI requests a day with SSH and SFTP unlimited, and the assistant writes the journalctl incantation onto your input line rather than executing anything itself. On a 6-inch screen at 2am, “suggest and wait” is the right default — we argued that out in full in letting AI run shell commands on mobile, safely. Disclosure: TermAI is our app.

Termius is the move if you want the same connection list on a laptop and a phone, or if a team needs shared hosts. It’s a bigger, desktop-first product with a mature vault; the trade is an account requirement and a heavier feel on mobile. Termius vs JuiceSSH has the direct comparison.

ConnectBot is the answer if the JuiceSSH thing you valued most was that it didn’t want anything from you. Free, open source, no account, no sync. It looks its age and has no SFTP, but it’s maintained and it does exactly one job.

Termux isn’t an SSH client so much as a Linux environment where OpenSSH happens to be installable. Excellent if you want ssh, tmux, rsync, and a package manager on your phone. Overkill if you just want to restart nginx from a train.

If you want the longer head-to-head, is JuiceSSH dead? The best alternatives for Android and the best SSH app for Android in 2026 go through the field in more detail.

How to not pick the next abandonware {#next-time}

JuiceSSH didn’t fail suddenly. It broadcast its status for four years and most of us weren’t checking. A ten-minute audit before you commit your keys to anything:

• Look at the last update date on the store listing. Not the version number — the date. More than 18 months for a security-sensitive app is a warning; more than three years is a decision to leave.
• Check whether there’s a changelog anyone is writing. A live changelog is the cheapest proof of a live project.
• Email support before you pay. A pre-sales question that goes unanswered for a week tells you what a bug report will get.
• Ask what happens to your data if the app dies. Can you export hosts? Can you get your keys out? “No” isn’t disqualifying, but it means you should plan to generate keys per-client and rotate rather than migrate — which is what step 3 above is really teaching.
• Prefer keys you can revoke over keys you have to rescue. If every client has its own key and every key is in authorized_keys with a comment saying which app it belongs to, retiring a dead app is one sed command, not a migration project.

That last one is the real lesson from this whole episode. The people who had a bad month were the ones whose only copy of a key lived inside an app that stopped working. The people who barely noticed were the ones who’d been rotating keys per-device all along.

FAQ {#faq}