Provisioning Servers & Deploying Your Project

Provisioning are the steps required to prepare a server for a RapidSMS project installation. Deployment is the process of continually syncing code to a production environment as changes are made and tested in a development environment.

RapidSMS projects can easily be installed in many ways.
Provisioning & Deployment are a large topics, contain many right answers and are largely dependent on your application requirements. Our goal is not to provide the best solution or a configuration that will work on any project. We only want to provide you with the proper resources to make the best decisions.
Document sane defaults.
While there are many installation methods, there’s a common denominator of best practices that all production RapidSMS sites should follow (don’t use DEBUG = True). We will document a concise list of best practices.
Example templates.
There are many options to consider: a bare metal server, cloud VM, platform as a service (PaaS). We don’t want to bless any single particular method, but we believe that linking to sample configurations for a small subset of these will provide a solid foundation and starting point for deploying your own application.

We can look at the overall production installation process in four parts:

When deploying RapidSMS, you might also need to consider Gateways and Telecom Operators.


Even if you don’t read anything else, the main things are:

  • Stop using runserver and switch over to Apache or your real server of choice.
  • Use a real database (not SQLite)
  • Turn off DEBUG!
  • Follow the guidelines in What to Provision.

You can find community-contributed examples on the GitHub wiki.