# Configuration Rocket aims to have flexible and usable configuration. Rocket applications can be configured via a configuration file, through environment variables, or both. Configurations are separated into three environments: development, staging, and production. The working environment is selected via an environment variable. ## Environment At any point in time, a Rocket application is operating in a given _configuration environment_. There are three such environments: * `development` (short: `dev`) * `staging` (short: `stage`) * `production` (short: `prod`) Without any action, Rocket applications run in the `development` environment. The environment can be changed via the `ROCKET_ENV` environment variable. For example, to launch an application in the `staging` environment, we can run: ```sh ROCKET_ENV=stage cargo run ``` You'll likely need `sudo` for the command to succeed since `staging` defaults to listening on port `80`. Note that you can use the short or long form of the environment name to specify the environment, `stage` _or_ `staging` here. Rocket tells us the environment we have chosen and its configuration when it launches: ```sh $ sudo ROCKET_ENV=staging cargo run 🔧 Configured for staging. => address: 0.0.0.0 => port: 80 => log: normal => workers: [logical cores * 2] => secret key: generated => limits: forms = 32KiB => tls: disabled 🛰 Mounting '/': => GET / 🚀 Rocket has launched from http://0.0.0.0:80 ``` ## Rocket.toml An optional `Rocket.toml` file can be used to specify the configuration parameters for each environment. If it is not present, the default configuration parameters are used. Rocket searches for the file starting at the current working directory. If it is not found there, Rocket checks the parent directory. Rocket continues checking parent directories until the root is reached. The file must be a series of TOML tables, at most one for each environment, and an optional "global" table. Each table contains key-value pairs corresponding to configuration parameters for that environment. If a configuration parameter is missing, the default value is used. The following is a complete `Rocket.toml` file, where every standard configuration parameter is specified with the default value: ```toml [development] address = "localhost" port = 8000 workers = [number_of_cpus * 2] log = "normal" secret_key = [randomly generated at launch] limits = { forms = 32768 } [staging] address = "0.0.0.0" port = 80 workers = [number_of_cpus * 2] log = "normal" secret_key = [randomly generated at launch] limits = { forms = 32768 } [production] address = "0.0.0.0" port = 80 workers = [number_of_cpus * 2] log = "critical" secret_key = [randomly generated at launch] limits = { forms = 32768 } ``` The `workers` and `secret_key` default parameters are computed by Rocket automatically; the values above are not valid TOML syntax. When manually specifying the number of workers, the value should be an integer: `workers = 10`. When manually specifying the secret key, the value should a 256-bit base64 encoded string. Such a string can be generated using a tool such as openssl: `openssl rand -base64 32`. The "global" pseudo-environment can be used to set and/or override configuration parameters globally. A parameter defined in a `[global]` table sets, or overrides if already present, that parameter in every environment. For example, given the following `Rocket.toml` file, the value of `address` will be `"1.2.3.4"` in every environment: ```toml [global] address = "1.2.3.4" [development] address = "localhost" [production] address = "0.0.0.0" ``` ## Extras In addition to overriding default configuration parameters, a configuration file can also define values for any number of _extra_ configuration parameters. While these parameters aren't used by Rocket directly, other libraries, or your own application, can use them as they wish. As an example, the [Template](https://api.rocket.rs/rocket_contrib/struct.Template.html) type accepts a value for the `template_dir` configuration parameter. The parameter can be set in `Rocket.toml` as follows: ```toml [development] template_dir = "dev_templates/" [production] template_dir = "prod_templates/" ``` This sets the `template_dir` extra configuration parameter to `"dev_templates/"` when operating in the `development` environment and `"prod_templates/"` when operating in the `production` environment. Rocket will prepend the `[extra]` tag to extra configuration parameters when launching: ```sh 🔧 Configured for development. => ... => [extra] template_dir: "dev_templates/" ``` ## Environment Variables All configuration parameters, including extras, can be overridden through environment variables. To override the configuration parameter `{param}`, use an environment variable named `ROCKET_{PARAM}`. For instance, to override the "port" configuration parameter, you can run your application with: ```sh ROCKET_PORT=3721 ./your_application 🔧 Configured for development. => ... => port: 3721 ``` Environment variables take precedence over all other configuration methods: if the variable is set, it will be used as the value for the parameter. Variable values are parsed as if they were TOML syntax. As illustration, consider the following examples: ```sh ROCKET_INTEGER=1 ROCKET_FLOAT=3.14 ROCKET_STRING=Hello ROCKET_STRING="Hello" ROCKET_BOOL=true ROCKET_ARRAY=[1,"b",3.14] ROCKET_DICT={key="abc",val=123} ``` ## Configuring TLS TLS (Transport Layer Security) is configured through the `tls` configuration parameter. The value of `tls` must be a table with two keys: * `certs`: _[string]_ a path to a certificate chain in PEM format * `key`: _[string]_ a path to a private key file in PEM format for the certificate in `certs` The recommended way to specify these parameters is via the `global` environment: ```toml [global.tls] certs = "/path/to/certs.pem" key = "/path/to/key.pem" ``` Of course, you can always specify the configuration values per environment: ```toml [development] tls = { certs = "/path/to/certs.pem", key = "/path/to/key.pem" } ``` In order for TLS support to be enabled, Rocket must be compiled with the `"tls"` feature. To do this, add the `"tls"` feature to the `rocket` dependency in your `Cargo.toml` file: ```toml [dependencies] rocket = { version = "0.2.8", features = ["tls"] } ```