Environment Variables

Environment variables are useful for feeding your application information from outside the running of that application. They are typically used to set things like database connection details and API keys.

Copy all copies all environment variables, allowing you to paste them elsewhere. Export to file exports all the environment variables; if you only want to export certain values, select the required environment variables and then click Export to file.

Special characters in environment variables

In the environment variable keys, you can only use a-z, 0-9, or underscore (_). Environment variable values are applied literally, with the exception of parentheses, commas, and double quotes.

Parentheses

Parentheses can cause the build or rollout process to fail, depending on when they are available during deployment. They cannot be used in environment variables.

Commas

Unescaped commas are interpreted as delimiters and cannot be used in environment variables.

• For example: write_stock,read_orders will cause the rollout process to fail.
• To keep a comma inside a string, escape it with a backslash (\) like this: write_stock\,read_orders — which will be applied as write_stock,read_orders.

Double quotes

Unescaped double quotes are either disregarded or will cause the rollout process to fail.

• For example, "my_example_variable" will be applied as my_example_variable.
• To keep double quotes around a variable, escape them with a backslash (\) like this: \"my_example_var\" — which will be applied as "my_example_var".
• If double quotes are inside of a string (e.g. my_exampl"e_text), the rollout process will fail.
• To keep double quotes inside a string, escape them with a backslash (\) like this: my_examp\"le_var — which will be applied as my_examp"le_var.

Base64 encoded variables

If your environment variable is Base64 encoded and you experience issues (e.g. 500 errors in the browser, build errors, runtime errors, etc.), try wrapping the value of the variable with single quotes.

Adding environment variables

To add environment variables after creating your application, click Environment variables > Add environment variable. Add the key-value pairs, select if the variables are to be available during runtime and/or the build process, and click Save.

You can reference another environment variable using the ${key} format. For example, to reference an environment variable with the key DB_PASSWORD use ${DB_PASSWORD}.

To add multiple environment variables, copy the keys and values using CMD + C (Mac) or CTRL + C (Windows), and in the Add environment variable window, press CMD + V (Mac) or CTRL + V (Windows). You can also paste the contents of a .env file or import the .env file using Import .env.

To deploy the changes, click Deployments > Deploy now.

Editing environment variables

You can edit variable names (keys) or values on the Environment variables page. To edit a variable, click the Edit (pencil) icon, make your changes, and click Save to update your variable(s). To deploy the changes, click Deployments > Deploy now.

When you create an internal connection and select the Add environment variables… checkbox, the variable names (keys) are automatically created. Some applications may expect environment variables with different names. For example, if you want to use a database with Laravel, the database.php file contains variable names different from those automatically created in MyKinsta. To use the variable names defined in the application, edit each variable as needed and change the key to match what’s defined in the database.php file.

Using environment variables

How you use environment variables depends on your application. In Node, for example, you can access a variable named API_KEY with process.env.API_KEY. In PHP, you would use getenv('API_KEY').

Internal connections and the build process

Internal connections are only available during runtime; they are not available during the build process.

If your application tries to connect to a database using an internal connection during the build process, this causes an error that says the database is not running, which makes the build fail. This is expected because the internal connection is not live during the build; it can only be used during runtime.

There are a couple of ways to work around this.

Option 1: Move the logic that connects to the database from the application’s build command to the start command. For example: if you have a command like prisma migrate in the build process and move that command to the start command, your application will only access the database during runtime, and the build will be successful.

Option 2: Add separate environment variables as needed for the database connection, one available for the build process, and the other only for runtime. The keys can be the same (e.g. DB_CONNECTION_URL) as long as one is only available during the build process and the other is only available during runtime. Use the database’s External connection details (Databases > dbname > Info > External connections) for the values of any variables to be used in the build process.

Environment variables set by Kinsta

Kinsta always sets PORT as the port used by the web server. If you’d like your application to interact with the web server, you will need to use this environment variable. For example, in Node.js, this is how you would start a server:

app.listen(process.env.PORT, () => {
console.log("Weather server is up and running")
})

Environment variables not set by Kinsta

By default, the NODE_ENV environment variable is not set to production for Node.js applications; you must add this environment variable manually.

Environment variable language examples

How you use environment variables depends on your application. The following table shows how to call an environment variable named API_KEY in various languages: