SMS gateway server requirements: sizing 1 to 200 msg/s

“What server do I need?” is the first question almost every buyer asks, and the answer is smaller than most people fear and more specific than most vendors say. An SMS gateway is not a video encoder. Its work is queueing, routing, billing and bookkeeping, and the bookkeeping is what grows. This guide gives you the SMS gateway server requirements at each traffic tier with real numbers, explains why dedicated vCPU matters more than core count, shows what delivery receipts and archives do to your disk over a year, and ends with a vendor shortlist and the backup plan you should have before the first client goes live.

SMS gateway server requirements by traffic tier

The number that decides your server is messages per second at peak, not messages per month. A client who sends 1,000,000 messages spread over a month averages 0.4 msg/s; the same client blasting a promotion to 200,000 numbers at nine in the morning wants 100 msg/s for half an hour. The gateway has to absorb that burst, hand it to the carriers as fast as they accept it, and then catch the delivery receipts that come back, which at peak arrive at the same rate as the sends did.

The table below is the sizing we publish on the platform page, and it matches what our own installations run on. The volumes are monthly, the rates are sustained.

Sustained rate	Monthly volume	Server	Notes
~1 msg/s	up to ~1,000,000 SMS	4 vCPU, 8 GB RAM, 100 GB SSD, everything on one box	Most resellers live here for their first year
~10 msg/s	~1,000,000 to 10,000,000	8 vCPU, 16 to 32 GB RAM, 250 to 500 GB SSD	Search index and database ideally on their own disks
~50 msg/s and up	10,000,000 and up	16+ vCPU, 32 to 64 GB RAM, fast NVMe, components split across nodes	Queue, database, search and the SMPP layer each get room

Two things surprise people in this table. First, how small the first tier is: a full multi-tenant platform with a web console, an SMPP server, a queue, a database and a search index fits on a 4 vCPU box, because at 1 msg/s none of them is under pressure. Second, the jump to the third tier is not about CPU. It is about I/O: at 50 msg/s the database writes a message row, updates it when the carrier acknowledges, updates it again when the receipt arrives, and indexes it for search. Three writes per message at 50 msg/s is 150 writes a second, sustained, plus reads from every client dashboard that is open. That is a disk problem, which is why NVMe and split nodes appear in the third row and not before.

The burst question: starting small, needing headroom

There is a common middle case the table does not capture: you are starting from zero, so your monthly volume is tiny, but your first client is a school chain or an e-commerce store that sends everything in one morning burst and expects it to land within minutes. You need 100 to 200 msg/s of headroom while your sustained rate is still under 1 msg/s.

The answer is a dedicated 4 to 8 vCPU server with 32 GB of RAM. It costs 50 to 100 USD a month at the providers listed below, it handles the burst because the cores are yours and the RAM keeps the queue and the working set in memory, and it carries you until sustained volume, delivery receipts and reporting start to compete for the same disk. That is the moment to move up a tier, and it usually arrives after the tenth client, not the first.

The most expensive beginner’s mistake in this business is buying the third tier on day one because a spreadsheet said you would have 50 clients. Buy the burst-ready first tier, watch the disk and the receipt queue, and move when the graphs tell you to.

Dedicated versus shared vCPU

Hosting price lists blur an important line. A “4 vCPU” shared instance gives you four time slices of cores that other tenants are also using; a “4 vCPU” dedicated instance gives you four cores that are yours. For a website the difference is invisible. For an SMS gateway it is the difference between a promotion landing in ten minutes and landing in forty.

The reason is the shape of the load. Web traffic is smooth and forgiving; a slow second here and there is invisible. SMS traffic is bursty and stateful: during a burst the SMPP layer must keep its carrier binds fed and answer their heartbeats on time, the queue must drain, and receipts must be matched back to messages while they are still hot in the database. When a shared core is being used by a neighbour at that moment, the bind stalls, the carrier’s window fills, the carrier throttles you, and your receipts pile up behind the sends. Nothing breaks, but everything you promised the client about speed and reporting is now late.

Rule of thumb: shared vCPU for the demo and the staging server, dedicated vCPU for anything a client pays for. The price gap at the first tier is 20 to 40 USD a month, which is less than one hour of your time explaining to a client why yesterday’s report is still updating.

RAM: what actually lives in memory

Memory needs are easier to reason about. Three things want to stay resident: the queue (every message that is accepted but not yet handed to a carrier, plus every receipt not yet matched), the database’s working set (the last few days of messages, the rate cards, the client accounts), and the search index’s cache. At the first tier all three together fit in 8 GB with room for the operating system and the web console. At the second tier the working set grows with your history, and 16 to 32 GB keeps the database from touching disk for the reports clients open every morning.

Where RAM runs out in practice is not the queue, it is reporting. A client asking for “all messages to this country last quarter” on a database that has to read that from disk turns a two-second query into a two-minute one and slows everyone else while it runs. Adding RAM is the cheapest fix; archiving old messages to a document store, which is what the third tier’s split design does, is the durable one.

Disk: delivery receipts and archives are the growth

The disk is where the real growth happens, and it is the part nobody sizes. Every message you send produces at least three records: the message itself, its delivery receipt from the carrier, and the billing entry that charged the client. Add the indexes that make search and reporting fast and a practical planning figure is about 1 KB per message all in, before compression.

At the first tier, 1,000,000 messages a month is roughly 1 GB a month of growth. A 100 GB SSD holds years of that. At the second tier, 10,000,000 messages a month is 10 GB a month, 120 GB a year, and a search index on top adds 30 to 50 percent, which is why the second row says 250 to 500 GB and why the search index and the database “ideally” sit on their own disks: they compete for the same write bandwidth when they share one.

Two design choices keep this from becoming a problem. First, an archive tier: the main database keeps the recent window (say 90 days) and older messages move to a document store where they are still searchable but no longer slow the transactional tables. Second, a retention policy you actually decide: many operators keep delivery receipts for 12 to 24 months for disputes and delete message bodies earlier, and some markets regulate the retention period, so confirm the rule for the countries you send into. A platform with an archive layer built in, which is how the Smppcube stack is drawn, with MongoDB as the archive next to MySQL as the system of record, makes both choices a setting rather than a project.

Network and ports

Bandwidth is not the constraint; a message is a few hundred bytes. What matters is a stable public IP, because carriers usually allowlist the IP of your SMPP bind and do not enjoy updating it, and open inbound port 2775 (or the port you choose) if your own clients will bind to your SMPP server. Behind that, HTTPS for the console and the HTTP API, and outbound access to the carriers’ SMPP and HTTP endpoints. If you run in a DMZ or air-gapped, the gateway only needs the carrier links and the console network, which is one of the reasons self-hosting works in regulated environments where a SaaS panel cannot even be approved.

A vendor shortlist with prices

Any provider that sells dedicated vCPU, SSD or NVMe storage, a static IP and lets you open a port will do. These are the ones we see most often. A dedicated 4 to 8 vCPU, 32 GB server, which covers the burst-ready first tier and the second tier’s CPU and RAM, typically costs 50 to 100 USD a month at any of the first four; the NVMe and split-node third tier is a custom quote everywhere.

Provider	Fits	Why it comes up
Hetzner	Europe	Dedicated vCPU plans and bare metal at low prices
Netcup	Europe	Dedicated cores at low cost; we run on Netcup ourselves
DigitalOcean	Worldwide regions	Simple console, predictable pricing, easy snapshots
OVHcloud	Europe, North America	Bare metal available when you outgrow virtual machines
Alibaba Cloud	Saudi Arabia and the Gulf	A data centre inside the Kingdom for data residency
Your own hardware	Air-gapped or regulated	Colocation fees only; the gateway needs nothing from outside except the carrier links

The “we run on Netcup ourselves” line is there because buyers ask; it is a statement of what works at the first two tiers, not a recommendation to ignore the others. Check current price lists before you decide. If your clients are in one country, a provider with a region there shortens the round trip to the carriers and, more importantly, keeps the data where the regulator expects it.

The whole bill, honestly

Server sizing only makes sense next to the rest of the bill, and this is where the self-hosted model earns its name. Three lines, and only one of them is ours:

1. The licence, once: 6,400 USD for the platform, every channel, every feature and the first year of support. That is the pricing page in one number.
2. The server, monthly: 50 to 100 USD at the first two tiers, paid to the provider you choose, in your own account, and you can move it whenever you like.
3. Your carrier traffic, at the rates you negotiate with your own SMSC or aggregator. We never sit in the middle of it.

Compare that with a rented panel where the platform fee scales with your traffic and the server is invisible because it is theirs: the server line is the one thing you cannot make cheaper by growing, and here it is the smallest line on the page.

Backups, monitoring and the boring parts

A server is not a plan. Before the first client goes live, three things should exist and be tested:

• A nightly backup that you have restored at least once. Database dump plus the configuration directory, copied off the machine (the provider’s snapshot is convenient, but a snapshot on the same account as the server is not a backup against the account being locked). Test the restore on the staging box; a backup nobody has restored is a hope.
• Disk and queue alerts. Two thresholds are enough: disk above 80 percent, and the receipt queue older than 15 minutes. The first tells you to archive or grow; the second tells you a carrier bind is unhealthy before a client does.
• A staging server. The cheapest shared VPS you can find, running the same version, where updates and new rate cards are tried first. Its cost is a coffee a month; its value is every update you do not have to roll back on the production box while clients are sending.

When you do not need any of this

If you send a few thousand messages a month from one application and have no clients of your own, you do not need a gateway server at all; an HTTP API from any vendor, called from your app, is the right size. The sizing in this guide is for operators who sell messaging to others: resellers, aggregators, operators, or a company running messaging for many internal teams. At that point the server is the least expensive part of the business, and knowing which tier you are in, and what will move you to the next one, is most of what “requirements” ever meant.