Configuration (sails.config)
The sails.config object contains the runtime values of your app's configuration. It is assembled automatically when Sails loads your app; merging together command-line arguments, environment variables, your .sailsrc file, and the configuration objects exported from any and all modules in your app's config/ directory.
More specifically, when you load your app, whether that's using node app, programmatic usage inside of a script, or sails lift, Sails will look in a few different places for configuration. Here they are listed in order of descending priority:
- an optional dictionary (
{}) of configuration overrides passed-in programmatically - command-line options parsed by minimist; e.g.
sails lift --mailgun.apiToken='token would be here' - environment variables prefixed with
sails_, and using double underlines to indicate dots; e.g.:sails_port=1492 sails lift(A few more examples) - a local
.sailsrcfile in your app's directory, or the first found looking in../,../../etc. - a global
.sailsrcfile in your home folder (e.g.~/.sailsrc) - files in your app's
config/directory (if one exists), withconfig/local.jstaking priority. Remember that, other thanlocal.js(which takes priority), the file names are just for convention: the configuration you export from each file gets deep-merged together with everything else into one big dictionary (sails.config).
The recommended solution for setting production config
Environment variables are one of the most powerful ways to configure your Sails app. Since you can customize just about any setting (as long as it's JSON-serializable), this approach solves a number of problems, and is our core team's recommended strategy for production deployments. Here are a few:
- Using environment variables means you don't have to worry about checking in your production database credentials, API tokens, etc.
- This makes changing Postgresql hosts, Mailgun accounts, S3 credentials, and other maintenance straightforward, fast, and easy; plus you don't need to change any code or worry about merging in downstream commits from other people on your team
- Depending on your hosting situation, you may be able to manage your production configuration through a UI (most PaaS providers like Heroku or Modulus support this, as does Azure Cloud.)
For a better experience on sailsjs.com, update your browser.
Reference
- Application
- Blueprint API
- Command Line Interface
-
Configuration
- sails.config.*
- sails.config.blueprints
- sails.config.bootstrap()
- sails.config.connections
- sails.config.cors
- sails.config.csrf
- sails.config.globals
- sails.config.http
- sails.config.i18n
- sails.config.log
- sails.config.models
- sails.config.policies
- sails.config.routes
- sails.config.session
- sails.config.sockets
- sails.config.views
-
Request (`req`)
- req.accepted
- req.acceptedCharsets
- req.acceptedLanguages
- req.body
- req.cookies
- req.fresh
- req.headers
- req.host
- req.ip
- req.ips
- req.isSocket
- req.method
- req.options
- req.originalUrl
- req.params
- req.path
- req.protocol
- req.query
- req.secure
- req.signedCookies
- req.socket
- req.subdomains
- req.url
- req.wantsJSON
- req.xhr
- req.accepts()
- req.acceptsCharset()
- req.acceptsLanguage()
- req.allParams()
- req.file()
- req.get()
- req.is()
- req.param()
- Response (`res`)
- Waterline (ORM)
- WebSockets
Built with Love
The Sails framework is maintained by a web & mobile studio in Austin, TX, with the help of our contributors. We created Sails in 2012 to assist us on Node.js projects. Naturally we open-sourced it. We hope it makes your life a little bit easier!
© 2012-2018 The Sails Company.
The Sails framework is free and open-source under the MIT License.