playSMS puts an SMS gateway, a bulk sender and a spam filter behind one web UI

A portal in front of the SMSC connection

playSMS is described as free and open source SMS management software, and the README is careful about what that means: a flexible Web-based mobile portal system that can be made to fit various services such as an SMS gateway, a bulk SMS provider, a personal messaging system, or corporate and group communication tools.

The architecture implied by that description is the important part. There is a real SMSC somewhere, the service provider's connection, and playSMS sits in front of it as a management layer. The gateway side is handled by a set of supported backends: Gammu, Kannel, SMS Server Tools, Jasmin, Playnet and Uplink, plus several SMS service providers. Multiple active SMSC are supported, and the whole point of that support is that a message leaves through one of several connections depending on rules you set.

The repository layout matches this reading. There is a web directory for the application, a daemon directory for the background workers, a db directory for the schema, a contrib directory, a documents directory, and an install-playsms.sh script with an install.conf.dist next to it. The project is PHP, with a composer.json, and it is licensed GPL-3.0 with the full text in LICENSE.md.

For a reader, the useful summary is that playSMS is not a library you call and not a service you sign up for. It is a piece of server-side software you install, configure with an SMSC, and then use through a browser or through its web services.

Routing is the feature that decides where messages go

The feature list is long, and most of it is about what happens to a message once it arrives. The routing options are the ones that carry real consequences, so they are worth pulling out.

Outgoing messages can be routed by prefix and routed per user, and incoming messages can be routed to users or to a URL. Rate can be applied by destination prefix. That is a set of rules covering who receives what, over which connection, and at what rate, which is a surprisingly complete set of levers for a messaging system.

The credit system is per user, and there is a blacklist, stoplist and firewall plugin for SMS service protections. Combined with the routing rules, this means playSMS can enforce a policy that a particular user may only send to numbers with a certain prefix, at a capped rate, and cannot use at all if they trip the firewall. That is the difference between a messaging tool and a managed messaging platform, and it is what makes the project interesting to anyone who has to account for abuse.

Multiple SMSC being activated and routable is the other half. A deployment with two provider connections can spread traffic between them or fail over, and because the routing rules select the destination, the choice of connection is a policy decision rather than a configuration detail.

The remaining features are about the message lifecycle. There is SMS autoreply for formatted replies to incoming messages, an SMS board that forwards received messages to email and exports output in JSON and other formats, and an SMS poll that manages a polling system over SMS with graph and JSON export. Long SMS support is there with a configurable text length, and a multi-language user interface in English, French, Bahasa Indonesia, Russian and a few others.

The unusual features are the ones worth understanding

Most of the feature list is recognisable messaging functionality. Four of the entries are not, and they are the ones that tell you what kind of tool this is.

SMS command executes a server side shell script using SMS. That is an administrative remote control for the machine, and it is a feature that any organisation deploying it should decide about deliberately rather than discover later.

SMS custom forwards incoming SMS to custom apps, locally or hosted on an external URL, which is the extension point that turns playSMS from a portal into a platform for whatever the receiving side happens to be.

SMS subscribe manages user subscriptions to a service using SMS, and SMS quiz serves quizzes over SMS. The subscribe one is a pattern that appears in every broadcast product: an opt-in keyword, a confirmation, a stop keyword, and a record of who is subscribed. Having it built in rather than bolted on means the confirmation and the stop handling are the same code path for every sender.

And there is SMS to email and email to SMS by polling mailbox, along with the mobile2web behaviour of receiving a private SMS into an inbox and forwarding it to email and to the user's phone. The polling design is the clue to the architecture: playSMS talks to mailboxes by polling them rather than being pushed to, which is how you integrate with a wide range of gateways that do not offer a callback.

Those four features are also the ones most likely to be turned off in a deployment, and each of them is a place where the security configuration matters.

Gateway plugins are how you add the next provider

The extensibility model is stated in one line in the feature list: create your own features, tools, themes and gateway modules as a plugin.

That is a broad surface, and it is the answer to the question every self-hosted messaging system eventually faces, which is what happens when the provider you chose changes its API. If a new bulk provider or a new SMSC type is not in the supported list, Gammu, Kannel, SMS Server Tools, Jasmin, Playnet and Uplink, then the option is a gateway module rather than a patch to the core.

Two details in the feature list make the plugin model more than a slogan. There is a simulation gateway for testing incoming and outgoing SMS, which means a plugin can be exercised without spending money on real messages, and the web services for sending SMS, retrieving delivery reports and checking credits are part of the standard surface.

The web services matter for the plugin story in particular. A custom application reached over a URL, receiving an incoming SMS as a forwarded message, is a plugin-free way to build the same thing, and the existence of both paths means the choice is between an in-process module and an HTTP endpoint.

The multi-domain feature is a third extension point of a different kind: multiple domains from a single playSMS installation with site branding for resellers. A deployment can therefore present itself as several branded portals from one codebase and one database, which is a hosting model rather than a feature, and it is the kind of thing that matters if you are running playSMS for clients rather than for yourself.

Installing it means reading INSTALL.md, not a command

The installation section of the README is two lines long, and the second one is the whole content: please read INSTALL, the playSMS installation document.

That is not an omission so much as a redirect. The INSTALL.md file sits at the top of the repository, next to README.md, and the supporting files around it describe a self-hosted PHP application rather than a package with a one-line install. There is a getcomposer.sh script, an install-playsms.sh script, and an install.conf.dist file that holds the configuration the installer reads, which is the traditional shape of a PHP application that wants to control its own dependencies and its own configuration directory.

The official project website is playsms.org, and there are companion sites for the other playSMS projects, the discussions board, and a separate docker-playsms repository for the containerised deployment. That last one is worth noting for anyone evaluating: the container image is maintained alongside rather than inside the main repository, so the Docker path is a second project to look at rather than a flag in this one.

The version to track is in the README itself. playSMS version 1.4.8-2508131200 is the current release line, and the version string itself encodes a build date, which tells you the project versions by build rather than by semantic version. The default branch is 1.4.x rather than main, so the branch name and the version line agree, and a team tracking releases should be aware they are following a maintenance branch rather than a trunk.

What to check before putting this on a network

There are three areas where a deployment decision matters more than the feature list, and none of them is settled by the documentation.

The first is the shell execution feature. SMS command runs a server side script from a message, and the project also supports forwarding incoming messages to a URL. Both are administrative capabilities that a messaging gateway needs and that an attacker with a sending number would love to have. The firewall plugin and the blacklist and stoplist are the tools for restricting who can do what, and deciding their configuration is part of installing this, not something to add later.

The second is the data. The credit system, the message archive behind the board and poll features, and the per-user routing all imply a database holding message content, sender identities and destination numbers. A database with that content needs the same care as any other store of personal data, and the multi-domain and reseller support means a single installation may serve several customers who should not see each other's data.

The third is the version cadence, and here the numbers are worth reading carefully. The recent releases are 1.4.8-2508131200 on 2025-08-13 and 1.4.7 on 2023-12-27, so the gap between the two most recent tags is about twenty months. The last push to the repository was on 2026-07-08, which is more recent than the last tag, so work has continued on the branch without a new release. The repository is not archived, but a project whose last published release is over a year old is not the same as one that ships monthly.

For a team evaluating this, the honest summary is that the feature set is broad and the extension model is good, and the operational questions around abuse control and message data are the ones the documentation leaves to you.

Editorial conclusion

playSMS suits an organisation that already has an SMSC connection or a bulk provider relationship and wants the routing, the user accounts and the delivery reporting in one self-hosted place, or a developer who wants to add a gateway by writing a plugin. It is the wrong tool for sending the occasional message to a handful of numbers, where an API and a script would do, and it is the wrong tool for a team that cannot take on running a PHP application and a database. Before you deploy it, read INSTALL.md, which the README points to as the installation document, plan the outbound number and sender rules deliberately, since the routing options are the part with real consequences, and check the security policy in the repository before you let it near a public network.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. playsms/playsms on GitHub
3. Project website
4. README
5. Releases