The pitch
httpSMS is an open-source SMS gateway that uses an Android phone as the modem. Instead of buying a virtual number or GSM hardware, you install the companion Android app, point your code at the HTTP API, and the server pushes a message to the phone, which sends it over the local SIM. Incoming messages can be forwarded to a webhook, and the platform adds AES-256 end-to-end encryption, rate limiting, back pressure, message expiration, and official Go and JavaScript/TypeScript clients. That makes it a candidate for OTP flows, outage alerts, or field notifications in countries where Twilio-style virtual numbers are not available.
The project is written in Go for the API and Nuxt/Vuetify for the hosted web UI, with a native Kotlin Android app. The self-hosted API uses Fiber, Go, and CockroachDB, and the hosted version runs on Google Cloud Run. For a self-hoster, that means the API is a normal Go service, but the phone-to-server loop depends on Firebase Cloud Messaging.
What happened when we ran it
We cloned the repo at commit 20adcdf on 2026-09-08 into a fresh Debian container with 3 CPUs, 8 GB RAM, and Go 1.24. The repo has 551 files and about 61,599 lines of source, checked out at 6.5 MB. The Go API installed in 71 seconds and pulled 625 packages. The build finished in 113 seconds. The test suite ran in 27 seconds: 20 tests passed, 0 failed. All of those numbers are ours, not from the project's CI.
We did not run the full self-host stack, which also requires a Firebase project, an SMTP server, Cloudflare Turnstile, and building the Android APK. So our verification covers the server code path and not the phone-to-server push loop. The build and test success does not prove the push notification flow works on a real Android phone; it only proves the Go code compiles and its 20 tests pass.
Strengths
The README is unusually specific about architecture. It includes a mermaid sequence diagram for sending a message, which shows the API returns 202 Accepted and the push flows to the Android app asynchronously. The feature list is concrete: end-to-end AES-256 encryption with the key stored only on the phone, webhook forwarding for inbound SMS, back pressure rate limiting, and message expiration when the phone misses a push notification. The repo also ships official API clients for Go and JavaScript/TypeScript, which reduces integration guesswork.
The Docker self-host guide is split into eight numbered steps, so even though the setup is heavy, nothing is hidden. The project uses AGPL-3.0, which is honest about copyleft: if you modify and host it as a service, you must release your changes. For a small team that just runs it internally, that is usually fine.
Weaknesses and rough edges
The biggest practical hurdle is setup breadth. The README's self-host path requires Firebase Cloud Messaging, SMTP credentials, Cloudflare Turnstile, environment variables, and a build-your-own Android app step. That is fine for a determined self-hoster, but it is not a one-command Docker Compose. Because the architecture depends on push notifications to the phone, delivery is not as deterministic as a directly connected modem: if the phone has no data or is offline, messages wait for a push and can expire.
The E2E encryption key is only on the phone, which is good for privacy but means a lost phone can make historical message content unrecoverable. The test suite is small at 20 tests; that is not proof of failure, but it is a lot less coverage than a complex distributed path would ideally have. The latest release tag is v1.2.1 from 2026-08-23, and the last push is today, 2026-09-08, so this is not a dead project, but release cadence is not heavy.
Community health
At review time the repo has 4,982 stars, 5 open issues, and a last push on 2026-09-08. The README links a Discord server and GitHub issues, and there are status badges for CI, code quality, uptime, and sponsors. Five open issues suggests either a low volume of trouble or a maintainer who closes things fast; with the recent push, activity looks current. The project is AGPL-3.0, so any hosted modifications come with copyleft obligations, which matters for some companies.
For a Go project with this many stars, the issue count is low, which can be a sign of a mostly personal project with a low support burden. The Discord server and sponsorship badges indicate a small but committed community rather than a large vendor-backed one.
Where it fits in a real stack
httpSMS sits behind an existing API gateway or automation tool, not in front of one. A typical use is a monitoring stack that already sends webhook alerts: point those alerts at the httpSMS API, and the Android phone becomes an out-of-band SMS notifier. Another is a small e-commerce flow that needs OTPs but cannot get a virtual number; the phone sends messages from a real local SIM, which can improve local deliverability.
Inbound webhook forwarding lets you build two-way SMS replies into a CRM or support tool. The back-pressure feature is useful here: if you blast 100 recipients, it will throttle to your configured messages-per-minute rather than tripping the Android SMS provider. The official Go client is a good fit if the rest of the stack is already Go; the Node client covers TypeScript frontends or lambdas.
Final take
The code is straightforward and the API design is simple, but the operational reality is that you are running a small distributed system: Firebase for push, SMTP for notifications, Turnstile for anti-abuse, and an Android phone that must stay charged and online. If you accept that operational tax, this is a practical way to get programmable SMS from a real SIM without a virtual number.