Lite is free. Pro adds the quality layer on top.
Keep API keysout of your code.
A key in code is a key in history. This is where keys belong, and the order to follow if one escapes.
// the steps
Six steps
01 Put keys in an env fileCreate a .env file for local work and read keys from the environment in code. The code names the variable, never the value.
02 Make git ignore itAdd .env to .gitignore before the first commit. Commit an example file with empty values so others know what to set.
03 Know public from secretA value shipped to the browser is public to everyone. Server only keys must never be given a public prefix to make an error go away.
04 Set the same keys on your hostAdd them in your deploy settings by hand. Do not commit them to move them.
05 Limit what a key can doUse the narrowest scope and set spending limits and alerts at the provider. A limited key is a smaller loss.
06 If one leaks, replace it firstCreate a new key, switch to it, and revoke the old one. Clean the history afterwards. Treat the old key as used.
// with adams
Where Adams fits
The commit is stopped for youLiteThe secret guards in Lite stop a key at commit, name the file and line without printing the value, and move it to an ignored env file. They are free.
// faq
Questions
Is a private repository safe enough?
It reduces exposure but does not remove it. Anyone with access can read the key. Keep keys out of code either way.
Can I store keys in a config file?
Not in one that is committed. A config file belongs in git, so it must hold no secrets.
How do I check for leaked keys?
Search your history with a secret scanner, and check your provider dashboard for use you do not recognise.
// related