Running a self-hosted SMS gateway: what it really takes

A self-hosted SMS gateway is one of those things that looks simple from the outside and reveals its real shape the week you go live. Sending a message is easy; sending millions reliably, charging for each one correctly, proving delivery, and doing it without a 2 a.m. outage is the actual work. This guide walks the architecture in plain terms, gives honest hardware numbers, marks the line where free software stops, and lays out the operations you will own the moment traffic is real. The goal is to help you decide with your eyes open, whether you build, buy, or stay renting a little longer.

What a self-hosted SMS gateway actually is

Underneath the dashboards, a gateway is a small assembly line with four stations. Traffic comes in, gets queued, gets sent, and gets accounted for. Understanding those four stations is most of the battle.

Ingress is how messages arrive. Business clients send over an HTTP API for convenience, over a web panel for one-off campaigns, or over an SMPP bind when they are another platform pushing high volume. SMPP is the telecom-native protocol: a persistent TCP connection, authenticated once, then messages stream over it as binary packets. A well-configured SMPP client can submit tens of thousands of messages a second, which is exactly why serious senders use it over HTTP.

The queue is the shock absorber. You never send straight from ingress to the carrier, because carriers accept at their own pace and your inbound bursts do not match it. Instead every accepted message lands in a fast in-memory queue (Redis is the common choice) and returns an acknowledgement immediately. This is what lets you accept a million-message blast in seconds without dropping any, then feed them to carriers steadily. Persistence on that queue matters: if the box reboots and the queue was memory-only, everything not yet written to disk is gone.

The bearer is the part that actually talks to carriers. In most self-hosted stacks this is Kannel, whose BearerBox holds the persistent SMPP connections to each SMSC (the carrier’s message centre), keeps them alive, reconnects when they drop, and balances traffic across sessions. A companion process reads the pending queue and hands messages to the bearer; another handles the delivery receipts and inbound messages coming back. This layer is decades old and extremely reliable, and there is no shame in standing on it.

Billing and accounting is the station everyone underestimates. Every message must be counted against the right client’s balance before it sends, priced by the route it took, refunded correctly when a carrier reports a hard failure, and rolled up into an invoice that a client can read. This is not a feature you bolt on later; it is woven through every other station, and it is where amateur gateways quietly lose money.

Server sizing: what you actually need at 1, 10, and 50 messages a second

The first sizing mistake is thinking in monthly totals. SMS traffic is bursty: a retailer’s flash sale or a bank’s overnight statement run pushes a month of volume through in an hour. What stresses the box is peak sustained throughput, the volume of delivery receipts flowing back (often as many events as messages sent), and the reporting and search load your clients generate. Size for the peak, not the average.

The table below is a starting point for a single-node deployment, not a contract. Message size, encoding, route mix, and how long you retain records all move the numbers.

Sustained throughput	Rough monthly volume	Starting hardware (single node)	What tends to bite first
~1 msg/s	Up to ~1,000,000	4 vCPU, 8 GB RAM, 100 GB SSD, all components together	Disk filling from logs and DLRs
~10 msg/s	~1,000,000 to 10,000,000	8 vCPU, 16 to 32 GB RAM, 250 to 500 GB SSD	Search and reporting under client load
~50 msg/s	10,000,000 and up	16+ vCPU, 32 to 64 GB RAM, fast NVMe, components split across nodes	Single-node limits; time to go active-active

Two practical notes. First, throughput to any single carrier is usually capped by the number of SMPP sessions the carrier permits, not by your hardware; if a route is slow while your box is idle, you probably need more sessions, up to the operator’s maximum, not a bigger server. Second, the moment the platform is business-critical, stop scaling one box and move to a high-availability topology with components on dedicated nodes. A documented baseline captured from your own deployment is worth more than any generic table, because “normal” is defined relative to your hardware and your traffic.

What open source gives you, and where it stops

The open-source SMS world is genuinely good, and pretending otherwise wastes your money. Kannel and Jasmin will terminate SMPP, hold carrier binds, and move enormous volume for the price of the server. If your need is a raw pipe between one system and one carrier, they are often the correct answer and you should not overbuy.

Where they stop is the business layer, and the gap is wider than it looks. Out of the box you do not get a graphical admin at all, so every route, rate, and user is a config file. You do not get multi-tenant client accounts, which means no per-client isolation, balances, or rates. You do not get billing, invoicing, or credit enforcement. You do not get white-label client portals, the readable delivery reports clients ask for, an opt-out engine, or anyone to call when a bind drops at midnight. None of that is a criticism of the tools; they were built to be a bearer, not a product. It simply means that turning a bearer into a business is a software project, and you should price that project honestly before you start it. That true cost of “free” is the subject of a dedicated comparison.

The operations nobody warns you about

Going live is the start of the work, not the end. Four operational realities will define whether your gateway is a business or a headache.

Delivery receipts (DLRs) are how you prove a message arrived, and they are not optional. A carrier returns a receipt saying delivered, failed, or expired, and your platform has to match it back to the original message, update the client’s report, and decide on billing. A soft failure (handset off, network congestion) may still deliver within its validity window and should not be refunded prematurely; a hard failure (invalid number, blocked) will never deliver and should be refunded. Getting this classification wrong is how you either lose money on refunds you should not give or anger clients by charging for messages that never landed.

Retries and validity decide what happens to messages that do not go through the first time. You need a sane retry policy and a validity period, or a stuck route silently piles up undelivered traffic until a client asks why their campaign never sent.

Monitoring is the difference between finding out from a graph and finding out from an angry client. At minimum, watch carrier bind status, queue depth, delivery ratio per route, and free disk. A gateway with no monitoring is not a smaller gateway; it is a time bomb with good intentions. One unglamorous reality worth internalizing: a surprising share of “everything is broken” incidents are simply a full disk, so check that first.

Backups are the one you will resent skipping. Your system of record, your client list, your balances, and your queue persistence all need a backup you have actually tested by restoring, not just scheduled. Test it once before you have clients, because the day you need it is the worst possible day to discover it never worked.

Build vs buy, honestly

Here is the fork, without a sales pitch. If you have engineering time, you enjoy owning the stack, and the messaging pipe itself is your product, building on open source is legitimate and cheap in license terms. You will spend that saving on the months it takes to build the billing, multi-tenant, portal, and reporting layers, and on maintaining them forever, but for some teams that is exactly the right trade.

If instead your goal is to sell messaging to clients this quarter, buying a platform you own outright is usually the better math. A one-time licensed platform like Smppcube ships the entire business layer, the multi-tenant accounts, billing, portals, and reporting, on top of the same battle-tested bearer, and runs on your own server so you keep the air-gap or DMZ posture that self-hosting is often chosen for in the first place. You trade a license fee for six to twelve months you do not spend building software that is not your differentiator.

The honest test is simple: is writing gateway software your business, or a distraction from it? Answer that first, and the architecture, sizing, and operations above become a checklist rather than a surprise. Start with your own peak-throughput number and a clear view of who you are selling to, and the rest of the decision makes itself.