Why we made Voltos

Life was sweet as a developer.

I ran my Cloud9 IDE in a browser so I could work on a Linux workspace from any computer. Docker let me push & pull images, spin up containers at will. GitHub stored and socialized my code.

When I was ready, I could deploy it to AWS or a platform like Heroku or Azure. And there was Firebase, Meteor, GraphQL, APIs, blah blah blah … And don't forget Selenium …

Of course, it wasn't perfect. But most of the time, it worked well. Really well.

Advanced platforms and tools that just made sense.

Elegance and productivity.

An age of wonders.

Except for credentials and secrets.

My apps would have credentials and secrets like:

I learned pretty quickly that you don't store them in source code because bad people can do bad things with them.

So don't store them in source code!

Use environment variables instead.


So I'd need to load them up from somewhere. I could load them from a bash script. Even better: tools like Figaro and dotenv helped me organise these variables as config files on my local environment.

Don't store config files in source control!

Right: I had to make sure that I didn't check these local config files into source control. (mental note: better not forget to update .gitignore)

Now if I needed to recreate my workspace and clone my source code — or deleted my config files by mistake — I'd have to manually recreate these files locally (because they certainly weren’t checked into source control).

And don't forget how to recreate them.

I'd store my Figaro or dotenv config files encrypted in 1Password and manually paste them into a new config file every time I had to recreate a workspace, after a git clone. (I’ve since discovered this is a common design pattern: others think me!).

How do we share credentials?

Then things got more complicated.

Tools like 1Password and Dashlane can share individual credentials but after a while, I got tired of copying and pasting lots of key-value pairs into my config files. After all, they're designed to be customer-facing apps, not dev tools.

So I'd end up storing a whole list of credentials in a secure place and sharing that whole list because it was just the path of least resistance. Maybe on Slack. Or iMessage. “Securely” (end-to-end sure, but not at the endpoints).

And I had to do all of the above again if I had to revoke or update a credential.

It was sticky notes but for code.

Some days, it makes me feel like this ■ By Arnold Reinhold, CC BY-SA 2.5, https://commons.wikimedia.org/w/index.php?curid=775153

This was not the age of wonders.

In fact, it felt like I was struggling with the equivalent of yellow sticky notes wherever I dealt with credentials … when everything else with which we were building code made sense & strove for elegance.

Rattic and Vault did make better sense. But they required you to build, configure & spin up infrastructure to run their platforms.

In the age of Heroku and Azure, it felt like most of our use cases are driving towards the simplicity of cloud platforms. Not building out infrastructure.

Could we manage our app credentials with the simplicity of:

git push heroku master

And have them available in a secure, central place wherever our apps can access them?

Voltos: a better way

Turns out that Glenn also had this problem.

We got together and built Voltos. It's a better way to store and share our credentials in a central, secure location.

And if you've ever struggled with the problem of credentials: it could help make your developer experience a good one again.

Managing your credentials in a way that makes sense.

Just like all our other tools.

Because we live in an age of wonders.

Daniel May

Things to see, people to do. Co-founder of Voltos. Co-founded @lifx. Advisor @beanhunter @chuffed energysolaris.com. Co-founder @launch48au startup events