View our GitHub

Please visit sails-docs on GitHub to view documentation on your mobile device.

Edit Page


If you have the immediate expectation of lots of traffic to your application (or better yet, you already have it!), you'll want to set up a scalable architecture that your app can scale as more and more people use it.


For the most part, Sails benchmarks exactly like any Connect, Express or app. This has been validated on a few different occasions, most recently here. If you have your own benchmark you'd like to share, please send a pull request to this page on Github.

Example architecture

Sails.js server
                    /  Sails.js server  \      /  Database (e.g. Mongo, Postgres, etc)
Load Balancer  <-->    Sails.js server    <-->    Socket store (Redis)
                    \  Sails.js server  /      \  Session store (Redis)
                       Sails.js server

Configuring your app for a clustered deployment

  • Make sure the database(s) for your models (e.g. MySQL, Postgres, Mongo) is scalable (e.g. sharding/cluster)
  • Configure your app to use a shared session store
    • Support for redis is built in (see the adapter options in config/session.js)
    • Configure your app to use a shared socket store
      • Support for redis is built in (see the adapter options in config/sockets.js)
      • The default configuration initially attempts to connect to the server using long-polling. In order for this to work, your server environment must support sticky load-balancing (aka sticky sessions), otherwise the handshake will fail until the connection is upgraded to use Websockets (and only if Websockets are available). On Heroku, you must have the sticky load-balancing beta feature explicitly enabled. In an environment without stickky load balancing, you will need to set the transports setting in config/sockets.js to ['websocket'], forcing it to use websockets only and avoid long-polling. You'll also need to set the transports in your socket client--if you're using, this is as easy as adding a <script>io.sails.transports=['websocket']</script> immediately after the script include. For a rather dramatic read on the issue, see this thread.
  • Ensure none of the other dependencies you might be using in your app rely on shared memory.

Deploying a Sails cluster on multiple servers

  • Deploy multiple instances (aka servers running a copy of your app) behind a load balancer
  • Configure your load balancer to terminate SSL requests
    • Because of this, you won't need to use the SSL configuration in Sails-- the traffic will already be decrypted

Is something missing?

If you notice something we've missed or could be improved on, please follow this link and submit a pull request to the sails-docs repo. Once we merge it, the changes will be reflected on the website the next time it is deployed.