How to set up environments for serverless functions?

I am working on serverless functions and my function includes API keys.

  1. How do I create 2 environments for my function? Is it possible to have a test and live environment?
  2. What’s the proper way of storing my staging and live API keys and how do I implement it in serverless functions? My current implementation is I have added the staging variables in the project.yml but I’m wondering how can implement a staging version and live version.


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Bobby Iliev
Site Moderator
Site Moderator badge
April 18, 2024


As we discussed recently here, similar to the standard development process, what you could do is to use a .env files with the required values.

You can template variables in project.yml from local .env files or App Platform environment variables.

You can substitute in variables from the runtime environment using the format "${SECRET_KEY}", where SECRET_KEY is the name of the variable specified in App Platform or your .env file:

environment: {}
parameters: {}
  - name: sample
    environment: {}
    parameters: {}
    annotations: {}
      - name: hello
        binary: false
        main: ''
        runtime: 'python:default'
        web: true
        parameters: {}
          SECRET_KEY: "${SECRET_KEY}"
        annotations: {}
        limits: {}

That way you never commit your .env file to GitHub and you control what the values are based on your environment.

By default, the doctl serverless deploy command will look for an .env file in the same directory as the project.yml file. You can also add an --env <path to .env-formatted file> flag to specify an alternate file name and location anywhere on the filesystem. So that way you could have and with different values.

Alternatively, if there are bigger differences in your dev and prod environments, you can even have separate project.yaml files. For example, you could have project.staging.yml and, each configured with appropriate environment variables. Then when deploying using the doctl, you can use the different files by passing the --config flag:

doctl serverless deploy package-name --config project.staging.yml

For more information about the available flags, you can take a look at the documentation here:

Let me know if you have any questions and if this works for you!



Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel