1Password and ngrok in Practice

As a longtime ngrok user, I have a couple different accounts for different projects. More importantly, I’ve started using our Bot Users capabilities to have separate projects within the same account. Either way, I end up with the problem of juggling multiple credentials in my local environment. While editing my ngrok.yml file each time was an approach, it was manual, annoying, and required having my credentials on screen which made for risky demos.

Enter the 1Password ngrok shell plugin.

With the 1Password ngrok shell plugin, instead of keeping your ngrok credentials in a local ngrok.yml file, you store them in 1Password. Then when you run the familiar: ngrok http 80 you authenticate into your 1Password vault, choose the authtoken you need, and the shell plugin loads the authtoken into memory for you.

Not only does this make my demos safer but it keeps credentials synchronized between machines without messaging myself or having to setup my environment twice. I can seamlessly move between my work and personal laptops - and even reset my authtoken - without having to update it in each location. 

Now let’s see it in action.

Setting up the 1Password ngrok shell plugin

There's a guide to the 1Password CLI integration for the detailed steps but at the highest levels, we have to install the 1Password app, install the 1Password CLI, connect the two, and then initialize the ngrok plugin. We’ll skip to that last step here.

First, we run:

op plugin init ngrok

And you should get this interface to add your authtoken to the vault:

Setting up the 1Password CLI with ngrok

Then we provide the authtoken, name it, decide which vault we put it in, and finally specify the scope. The is the most powerful part and has three options:

  • First, we can have the plugin prompt us on which credential to use every time we start a new shell. This is what I use so I can operate between different accounts easily but this probably isn’t the choice for you.
  • Second, we can have the plugin automatically use this credential for this directory and all of its subdirectories. If you have multiple projects, this is the choice for you. It’s a simple way to keep your projects’ environments separate and not accidentally reset a token and surprise yourself.
  • Finally, you can have the plugin use this credential as the global default. Most people will ant to start here but I’d recommend the second per-directory approach for project-level isolation.

Do the above for each credential you have and then delete those credentials from your ngrok.yml file. You won’t need them anymore. Now let’s see it in action!

Using the 1Password ngrok shell plugin

Now that we have our environment configured, we start our tunnel just as we always would:

ngrok http 80

The 1Password CLI will intercept the request and request access to our vault. Now you log into 1Password as you normally would - password, Touch ID, etc - and 1Password will choose the credential or prompt you as you chose in the last step.

In practice, it looks like this:

Using 1Password to manage ngrok authtokens

Using the 1Password ngrok shell plugin for teams

Now that you have 1Password set up for your account, you don’t have to stop there. With a Teams or Business account, you can issue and manage ngrok credentials centrally based on teams, projects, or even individuals without anyone ever needing to log into the ngrok Dashboard.

1Password and ngrok in practice

I installed the 1Password integration as soon as it became available. Despite being a longtime customer of both, I was skeptical if it would make using one or both platforms more painful. After a few weeks using it on a near-daily basis, I have to say that I love it. It was clear and simple to setup, solved a real problem for me, and now my ngrok credentials follow me wherever I need them. It’s hard to beat that.

Share this post
Keith Casey
Keith Casey serves on the Product/GTM Team at ngrok helping teams launch their systems faster and easier than ever before. Previously, he served on the Product Team at Okta working on Identity and Authentication APIs, as an early Developer Evangelist at Twilio, and worked to answer the Ultimate Geek Question at the Library of Congress. His underlying goal is to get good technology into the hands of good people to do great things. In his spare time, he writes at CaseySoftware.com and lives in the woods. He is also a co-author of A Practical Approach to API Design.
Cool tools