The Serverless Toolkit has support for two types of meta files that can be included in your project:
.twilioserverlessrc
— a configuration file.
.twiliodeployinfo
— an autogenerated meta file.
These configuration files are only supported by @twilio-labs/plugin-serverless version 2.0.0 or newer and twilio-run version 3.0.0 or newer. For older versions, check out the section for .twilio-functions further down.
By default, the Serverless Toolkit will try to load any configuration file from the root of your project by looking for .twilioserverlessrc. The format of the configuration file is JSON5 which supports regular JSON as well as features such as comments. Additionally, we support alternative formats for your configuration file. You can select any of these by by adding a suitable file extension:
.twilioserverlessrc.js
or
.twilioserverlessrc.cjs
— Important: you'll have to export an object using
module.exports = { ... }
.twilioserverlessrc.yml
"twilioserverless"
key to your
package.json
twilioserverless.config.js
You can also provide a different location for your config file by specifying the location using the -c flag.
In this guide we'll use the JSON5 syntax.
In general, everything that can be configured using a CLI flag with the Serverless Toolkit is also accessible through the configuration. By convention, every configuration value uses lowerCamelCase notation: for example, --service-sid becomes serviceSid in the configuration. Here are some further examples:
_43{_43 "commands": {},_43 "environments": {},_43 "projects": {},_43 // "assets": true /* Upload assets. Can be turned off with --no-assets */,_43 // "assetsFolder": null /* Specific folder name to be used for static assets */,_43 // "buildSid": null /* An existing Build SID to deploy to the new environment */,_43 // "config": null /* Location of the config file. Absolute path or relative to current working directory (cwd) */,_43 // "createEnvironment": false /* Creates environment if it couldn't find it. */,_43 // "cwd": null /* Sets the directory of your existing Serverless project. Defaults to current directory */,_43 // "detailedLogs": false /* Toggles detailed request logging by showing request body and query params */,_43 // "edge": null /* Twilio API Region */,_43 // "env": null /* Path to .env file for environment variables that should be installed */,_43 // "environment": "dev" /* The environment name (domain suffix) you want to use for your deployment */,_43 // "extendedOutput": false /* Show an extended set of properties on the output */,_43 // "force": false /* Will run deployment in force mode. Can be dangerous. */,_43 // "forkProcess": true /* Disable forking function processes to emulate production environment */,_43 // "functionSid": null /* Specific Function SID to retrieve logs for */,_43 // "functions": true /* Upload functions. Can be turned off with --no-functions */,_43 // "functionsFolder": null /* Specific folder name to be used for static functions */,_43 // "inspect": null /* Enables Node.js debugging protocol */,_43 // "inspectBrk": null /* Enables Node.js debugging protocol, stops execution until debugger is attached */,_43 // "legacyMode": false /* Enables legacy mode, it will prefix your asset paths with /assets */,_43 // "live": true /* Always serve from the current functions (no caching) */,_43 // "loadLocalEnv": false /* Includes the local environment variables */,_43 // "loadSystemEnv": false /* Uses system environment variables as fallback for variables specified in your .env file. Needs to be used with --env explicitly specified. */,_43 // "logCacheSize": null /* Tailing the log endpoint will cache previously seen entries to avoid duplicates. The cache is topped at a maximum of 1000 by default. This option can change that. */,_43 // "logLevel": "info" /* Level of logging messages. */,_43 // "logs": true /* Toggles request logging */,_43 // "ngrok": null /* Uses ngrok to create a public url. Pass a string to set the subdomain (requires a paid-for ngrok account). */,_43 // "outputFormat": "" /* Output the log in a different format */,_43 // "overrideExistingProject": false /* Deploys Serverless project to existing service if a naming conflict has been found. */,_43 // "port": "3000" /* Override default port of 3000 */,_43 // "production": false /* Promote build to the production environment (no domain suffix). Overrides environment flag */,_43 // "properties": null /* Specify the output properties you want to see. Works best on single types */,_43 // "region": null /* Twilio API Region */,_43 // "runtime": null /* The version of Node.js to deploy the build to. (node10 or node12) */,_43 // "serviceName": null /* Overrides the name of the Serverless project. Default: the name field in your package.json */,_43 // "serviceSid": null /* SID of the Twilio Serverless Service to deploy to */,_43 // "sourceEnvironment": null /* SID or suffix of an existing environment you want to deploy from. */,_43 // "tail": false /* Continuously stream the logs */,_43 // "template": null /* undefined */,_43}
Some configuration properties are shared across multiple commands and will always be executed. However, there are situations where you might want a configuration to apply only in certain scenarios. This is where scoped configurations come into play.
In addition to defining configuration values on a top level, you can scope them to:
commands
: based on the CLI command you use, e.g.,
start
,
deploy
,
list
,
promote
,
logs
, etc.
environments
: based on the value you pass to
--environment
or by using
"*"
for
--production
.
projects
: based on the Account SID you deploy to. This doesn't work if you use
--username
and
--password
with
twilio-run
unless you specify an Account SID.
Which one you use depends on your set up but some common use cases are:
Another common example is using different environment variables for different environments. Take the following configuration:
_13{_13 "environments": {_13 "dev": {_13 "env": ".env.dev"_13 },_13 "stage": {_13 "env": ".env.stage"_13 },_13 "*": {_13 "env": ".env.prod"_13 }_13 }_13}
In this case depending on which value you pass to --environment it will also change the .env file the CLI will read to get environment variables. More specifically:
twilio serverless:deploy
uses the file
.env.dev
twilio serverless:deploy --environment stage
uses the file
.env.stage
twilio serverless:deploy --production
uses the file
.env.prod
twilio serverless:start
falls back to the default meaning
.env
This file keeps track of information resulting from your latest deployments. It does so on a per-project basis to make sure when you redeploy and switch between CLI profiles, we will still deploy to the right account. This file is autogenerated and you typically do not have to modify it yourself.
By default, this file is included into your .gitignore since it should not be relevant for orther people using the same codebase. If you do share Twilio accounts/credentials, you should instead configure the different serviceSid values in the configuration file. Check out this guide for more information.
In previous versions of the Serverless Toolkit you might have found a .twilio-functions file. This file was fulfilling the role of the .twilioserverlessrc and .twiliodeployinfo files with less functionality and more confusion. We deprecated this file in new versions. If you have this file in your project and want to upgrade the latest version of the Serverless Toolkit, you should run the following command to migrate:
_10npx -p twilio-run twilio-upgrade-config
This will convert your .twilio-functions file into a .twiliodeployinfo file. If you are using custom configuration, you might have to copy some of that into the .twilioserverlessrc file manually.