Your application configuration lives in the `config` folder. All the configuration files are loaded on startup and can be accessed through the configuration provider.
or a function returning a configuration object (recommended usage). The function will get access to the [`env` utility](#casting-environment-variables).
Now you can access those variables in your configuration files and application. You can use `process.env.{varName}` to access those variables anywhere.
Strapi configurations can also be created per environment in `./config/env/{env}/{filename}`. These configurations will be merged into the base ones defined in the `./config` folder.
The environment is based on the `NODE_ENV` environment variable (defaults to `development`).
When starting strapi with `NODE_ENV=production` it will load the configuration from `./config/*` and `./config/env/production/*`. Everything defined in the production config will override the default config.
| `admin.autoOpen` | Enable or disabled administration opening on start. | boolean | `true` |
| `admin.path` | Allow to change the URL to access the admin panel. | string | `/admin` |
| `admin.watchIgnoreFiles` | Add custom files that should not be watched during development. See more [here](https://github.com/paulmillr/chokidar#path-filtering) (property `ignored`). | Array(string) | `[]`. |
The `./config/functions/` folder contains a set of JavaScript files in order to add dynamic and logic based configurations.
All functions that are exposed in this folder are accessible via `strapi.config.functions['fileName']();`
### Bootstrap
**Path —** `./config/functions/bootstrap.js`.
The `bootstrap` function is called at every server start. You can use it to add a specific logic at this moment of your server's lifecycle.
Here are some use cases:
- Create an admin user if there isn't one.
- Fill the database with some necessary data.
- Check that the database is up-and-running.
- Load some environment variables.
The bootstrap function can be synchronous or asynchronous.
**Synchronous**
```js
module.exports = () => {
// some sync code
};
```
**Return a promise**
```js
module.exports = () => {
return new Promise(/* some code */);
};
```
**Asynchronous**
```js
module.exports = async () => {
await someSetup();
};
```
### CRON tasks
CRON tasks allow you to schedule jobs (arbitrary functions) for execution at specific dates, with optional recurrence rules. It only uses a single timer at any given time (rather than reevaluating upcoming jobs every second/minute).
This feature is powered by [`node-schedule`](https://www.npmjs.com/package/node-schedule) node modules. Check it for more information.
::: warning
Make sure the `enabled` cron config is set to `true` in `./config/server.js` file.
:::
The cron format consists of:
```
** ** * *
┬ ┬ ┬ ┬ ┬ ┬
│ │ │ │ │ |
│ │ │ │ │ └ day of week (0 - 7) (0 or 7 is Sun)
│ │ │ │ └───── month (1 - 12)
│ │ │ └────────── day of month (1 - 31)
│ │ └─────────────── hour (0 - 23)
│ └──────────────────── minute (0 - 59)
└───────────────────────── second (0 - 59, OPTIONAL)
```
To define a CRON job, add your logic like below:
**Path —** `./config/functions/cron.js`.
```js
module.exports = {
/**
* Simple example.
* Every monday at 1am.
*/
'0 0 1 * * 1': () => {
// Add your own logic here (e.g. send a queue of email, create a database backup, etc.).
},
};
```
### Database ORM customization
When present, they are loaded to let you customize your database connection instance, for example for adding some plugin, customizing parameters, etc.
:::: tabs
::: tab Mongoose
As an example, for using the `mongoose-simple-random` plugin for MongoDB, you can register it like this:
**Path —** `./config/functions/mongoose.js`.
```js
'use strict';
const random = require('mongoose-simple-random');
module.exports = (mongoose, connection) => {
mongoose.plugin(random);
};
```
:::
::: tab Bookshelf
Another example would be using the `bookshelf-uuid` plugin for MySQL, you can register it like this:
-`debug` (boolean): Show database exchanges and errors.
-`autoMigration` (boolean): To disable auto tables/columns creation for SQL database.
-`pool` Options used for database connection pooling. For more information look at [Knex's pool config documentation](https://knexjs.org/#Installation-pooling).
-`min` (integer): Minimum number of connections to keep in the pool. Default value: `0`.
-`max` (integer): Maximum number of connections to keep in the pool. Default value: `10`.
-`acquireTimeoutMillis` (integer): Maximum time in milliseconds to wait for acquiring a connection from the pool. Default value: `2000` (2 seconds).
-`createTimeoutMillis` (integer): Maximum time in milliseconds to wait for creating a connection to be added to the pool. Default value: `2000` (2 seconds).
-`idleTimeoutMillis` (integer): Number of milliseconds to wait before destroying idle connections. Default value: `30000` (30 seconds).
-`reapIntervalMillis` (integer): How often to check for idle connections in milliseconds. Default value: `1000` (1 second).
-`createRetryIntervalMillis` (integer): How long to idle after a failed create before trying again in milliseconds. Default value: `200`.
-`environment` (string): Sets the environment you want to store the data in. By default it's current environment (can be an empty string if your config is environment agnostic).
-`type` (string): Sets if your config is for an `api`, `plugin` or `core`. By default it's `core`.
-`name` (string): You have to set the plugin or api name if `type` is `api` or `plugin`.
-`key` (string, required): The name of the key you want to store.
