Before you launch any web application, you should ask yourself a few questions:
sails.log()in combination with a hosted service like Papertrail?
NODE_ENVenvironment variable set to "production"?
NODE_ENV=production node app(or, as a shortcut:
sails lift --prod).
You can provide configuration which only applies in production in a few different ways. Most apps find themselves using a mix of environment variables and
config/env/production.js. But regardless of how you go about it, this section and the Scaling section of the documentation cover the configuration settings you should review and/or change before going to production.
Node.js is pretty darn fast. For many apps, one server is enough to handle the expected traffic-- at least at first.
This section focuses on single-server Sails deployment. This kind of deployment is inherently limited in scale. See Scaling for information about deploying your Sails/Node app behind a load balancer.
Many teams decide to deploy their production app behind a load balancer or proxy (e.g. in a PaaS like Heroku or Modulus, or behind an nginx server). This is often the right approach since it helps future-proof your app in case your scalability needs change and you need to add more servers. If you are using a load balancer or proxy, there are a few things in the list below that you can ignore:
If your app uses sockets and you're using nginx, be sure to configure it to relay websocket messages to your server. You can find guidance on proxying WebSockets in nginx's docs on the subject.
NODE_ENVenvironment variable to
Configuring your app's environment config to
'production' tells Sails to get its game face on; i.e. that your app is running in a production environment. This is, hands down, the most important step. If you only have the time to change one setting before deploying your Sails app, this should be that setting!
When your app is running in a production environment:
migrate: 'safe'. This is a failsafe to protect against inadvertently damaging your production data during deployment.
.jsfiles to decrease page load times and reduce bandwidth consumption.
res.serverError()will still be logged, but will not be sent in the response (this is to prevent a would-be attacker from accessing any sensitive information, such as encrypted passwords or the path where your Sails app is located on the server's file system)
Note: If you set
'production'some other way, that's totally cool. Just note that Sails will either set the
NODE_ENVenvironment variable to
'production'for you automatically (or otherwise log a warning-- so keep an eye on the console!). The reason this environment variable is so important is that it is a universal convention in Node.js, regardless of the framework you are using. Built-in middleware and dependencies in Sails expect
NODE_ENVto be set in production-- otherwise they use their less efficient code paths that were designed for development use only.
If you have sockets enabled for your app (that is, you have the
sails-hook-sockets module installed), then for security reasons you'll need to set
sails.config.sockets.onlyAllowOrigins to the array of origins that should be allowed to connect to your app via websockets. You&rsuqo;ll likely set this in your app’s
config/env/production.js file. See the socket configuration documentation for more info on
Whether it's by using the
sails_port environment variable, setting the
--port command-line option, or changing your production config file(s), add the following to the top level of your Sails config:
As mentioned above, ignore this step if your app will be running behind a load balancer or proxy.
If all of your app’s models use the default datastore, then setting up your production database is as simple as configuring
sails.config.datastores.default in the config/env/production.js file with the correct settings.
If your app is using more than one database, your process will be similar. For every datastore used by the app, add an item to the
sails.config.datastores dictionary in config/env/production.js.
Keep in mind that if you are using version control (e.g. git), then any sensitive credentials (such as database passwords) will be checked in to the repo if you include them in your app's configuration files. A common solution to this problem is to provide certain sensitive configuration settings as environment variables. See Configuration for more information.
If you are using a relational database such as MySQL, there is an additional step. Remember how Sails sets all your models to
migrate:safe when run in production? That means no auto-migrations are run when lifting the app...which means by default your tables won't exist. A common approach to deal with this during the first-time setup of a relational database for your Sails app goes as follows:
'production', and leave your models' configuration set to
migrate: 'alter'. Now run
sails liftonce-- and when the local server finishes lifting, kill it.
If this makes you nervous or if you can't connect to the production database remotely, you can skip the steps above. Instead, simply dump your local schema and import it into the production database.
Protecting against CSRF is an important security measure for Sails apps. If you haven't already been developing with CSRF protection enabled (see
sails.config.security.csrf), be sure to enable CSRF protection before going to production.
If your API or website does anything that requires authentication, you should use SSL in production. To configure your Sails app to use an SSL certificate, use
As mentioned above, ignore this step if your app will be running behind a load balancer or proxy (e.g. on a PaaS like Heroku).
The last step of deployment is actually starting the server. For example:
NODE_ENV=production node app.js
Or if you're more comfortable with command-line options you can use
node app.js --prod # (Sails will set `NODE_ENV` automatically)
As you can see, instead of
sails lift you should start your Sails app with
node app.js in production. This way, your app does not rely on having access to the
sails command-line tool; it just runs the
app.js file bundled in your Sails app (which does exactly the same thing).
Unless you are not deploying to a PaaS like Heroku, you will want to use a tool like
forever to make sure your app server will start back up if it crashes. Regardless of the daemon you choose, you'll want to make sure that it starts the server as described above.