Your Gateway, Your Data

2026-09-06

Every SMS aggregator works the same way underneath the branding: your message goes to their servers first, gets logged, billed, and then routed onward. That's true whether it's Twilio, a smaller reseller running on top of Twilio's network, or any of the platforms selling "SMS API" access by the message. The pitch is convenience — one API key, global carrier reach — but the mechanism is that a third party sees every message that moves through your business, keeps a record of it, and charges you a fraction of a cent every time one passes through.

For plenty of use cases that trade-off is fine. For a lot of others — a clinic forwarding appointment confirmations, a team routing password-reset codes, anyone handling anything a customer would rather not have sitting in a stranger's database — it's a trade-off worth questioning.

Two different roads to "your own SIM"

There's a small but real category of tools that avoid the aggregator model by putting a real Android phone and SIM card back in the loop, and they land on the same idea from different angles. SMSGate (the open-source capcom6/android-sms-gateway project) and httpSMS both turn a phone into a self-hosted SMS gateway you run yourself, aimed squarely at developers comfortable standing up their own server and managing the moving parts. Traccar, better known for GPS fleet tracking, ships its own SMS gateway app for a similar reason — commands need to reach a real SIM without a paid aggregator sitting in between. All three prove the same point: the demand for "my phone, my SIM, no middleman" is real enough that multiple independent projects have converged on it.

What they don't solve is the setup and maintenance overhead. Self-hosting means someone owns patching the server, watching for it to fall over, and rebuilding the pipeline every time an API changes.

There's a second, quieter difference worth checking for yourself rather than taking anyone's word for: whether a message you receive counts against the same limit as one you send. httpSMS's plan caps (200 messages a month on its free tier, at time of writing) apply to sent and received messages combined — an overage notice from the service adds both together against one number. textbee.dev does the same in its own open-source billing code: receive_sms and send_sms are checked against the identical dailyLimit/monthlyLimit in billing.service.ts, and the check runs on the incoming-message path too, in gateway.service.ts — you can read it yourself in their repository. Forwarding is unmetered on every Pushferry plan, including the free one: we never bill you for a message you didn't choose to receive.

What "never stored" actually means here

Pushferry sits between those two extremes. The phone with the SIM card stays physically in your possession — nobody mails a card to a data center, nobody ports the number into a platform you don't control. But you don't run your own server or maintain your own gateway software either. Messages get forwarded to Slack, Discord, email, a webhook, or a REST API, and the message text itself is never stored on Pushferry's server. It passes through to get delivered, and then it's gone — there's no message archive to subpoena, breach, or accidentally leave in a database backup.

That's a meaningfully different privacy posture from an aggregator that keeps message logs by design, often because billing and delivery reporting depend on that log existing. It also means Pushferry isn't in the business of reading your traffic to build analytics products or ad targeting around it — there's nothing to build from, because there's nothing retained.

Why this matters more than it sounds like it should

None of this makes Pushferry a compliance product or a substitute for a business working through its own data-handling obligations carefully — that's still its own job. But the architecture itself removes an entire category of exposure: a phone that's yours, a number that's yours, and a message that's never sitting on someone else's server waiting to become the subject of a breach notification. Aggregators charge per message partly because storing and routing that message is the product. Pushferry charges per connected phone because forwarding what's already yours, without keeping a copy, is the whole job.