Using Environment Variables with Tonic

Since documents are public on Tonic, a common question is how you can safely interact with APIs or services without exposing your credentials. The answer is to use environment variables.

These work just like the shell environment variables you’re used to. You set them on the settings page, and then you can access them in any notebook, like this:

var mySecret = process.env.SECRET;
doSomethingWith(mySecret);

Everything in your environment stays with your account. When people clone a notebook, your environment won’t go with it. Be aware, however, than if you log the value of an environment variable, or return it as the output of a code cell, that will be visible to everyone.

You can have as many variables as you like, and we’ve also made a few handy integrations that make it easy to get set up with OAuth credentials for popular services. These credentials will never be used by us; they’re entirely for you to use in your own notebooks.&nbsp

1 Like

Thanks for offering this feature! I’ve had success with it in a few notebooks already.

Today, for some reason, new environment variables that I add are immediately forgotten. I haven’t worked out what’s going on. Is it possible this is realted to the migration from “tonicdev” to “runkit”?

Sorry about that. We temporarily introduced a bug here, and it’s now fixed. Thanks for reporting it!

Is there any way to make this work for embedded notebooks? I want to securely provide API credentials in a set of embedded notebooks in my own application, without exposing them on the front-end.

Thanks for adding this feature. Could I suggest adding a line of text to the RunKit explaining how to access the variable?

The ‘FOO’ environment variable is now available at ‘process.env.FOO’

(I only figured it out by finding this discussion thread…)

Probably also worth making clear that these are not JavaScript variables. So if you do this:

FOO = { name: ‘BAR’ }

Then process.env.FOO is a string, which you would have to parse with JSON.parse(process.env.FOO).

(For that matter…why not have JavaScript variables instead of environment variables? Seems a bit weird in a way…)