Best way to store secrets (API Keys, etc.)

Best Practice
1

Is there a best practice for storing secrets? I am not worried about the end user/app user obtaining a secret as I’m using them in cloud code. But, cloud code gets pushed to GitHub if GitHub is used for versioning.

Is there a way to store and inject environment variables to store secrets? Is there a better way to store secrets so they don’t get pushed to GitHub?

2

Hi Alex! I would create a shared task in CloudCode and then add e.g. a config file to that task, and then add that to the gitignore file. You can export them and include those in runtime but not push them to Github.
There is a tangential reference to that in this post: How to run unit tests?

1 Like
3

Another option is to store them in the DB and exclude them from sync rules and load them into memory in the CC task logic. They are then effectively environment variables and are encrypted at rest.

1 Like
4

.gitignore is not a viable option unfortunately - for GitHub apps, OXIDE loads the files from the GitHub repo. Anything in the .gitignore will by definition not store anything in the git repo.

We definitely want to get first class support for environment variables into the roadmap.

5

Update: the best practice recommendation for storing secrets is now to use OXIDE’s native support for environment variables. To use:

  • Variables are stored per-deployment, so navigate to your Deployments in OXIDE
  • Click on “Deployment Settings” for the desired deployment (e.g. Staging)
  • Select the “Environment Variables” tab - here you can add variables

Once you’ve defined your variable, you can access it from your CloudCode task using process.env.VARIABLE_NAME

available from CloudCode version 1.11.1

1 Like