Building Blip: The Complete Toolkit for Your IP-Whitelisted Servers

Some background on Blip, the tool I'm currently working on. Blip connects to your cloud providers and gives you self-destructing firewalls, whitelist scheduling, teams, secure sharing, and IP syncing from popular cloud services.

Joe Tannenbaum

I am currently working on Blip, a utility belt for your IP-whitelisted servers. It connects to your cloud providers and gives you self-destructing firewalls, whitelist scheduling, teams, secure sharing, and IP syncing from popular cloud services. It will launch with support for DigitalOceanAWS, and Laravel Forge.


Whenever possible, it's a good idea to only let people SSH into a server from specific IP addresses.

I work on a lot of client sites and have many of my own projects, all of which are set up this way. I work remotely, so depending on where I was working that day, I would occasionally have to log in to whichever cloud provider I was using and add a rule to whitelist my IP address in order to log into a server.

I found this to be cumbersome, so I built myself an Alfred workflow that connected to these providers via their APIs. I typed addmyip into Alfred, selected the provider, and it would do the rest. I happily used this for years and it did the job really well.

A Tidal Wave of IP Addresses

Over the past year, my wife and I traveled for her job. A lot. We were constantly in new places, and I just worked from whichever city we were in at the moment. Airbnbs, coffee shops, hotels, co-working spaces, wherever I could find decent internet. Suddenly I was adding IPs left and right, and constantly having to remember to delete them afterward. And there I was, back to constantly logging into cloud providers and deleting rules.

I decided I needed these rules to be self-destructing so I wouldn't have to remember to clean up after myself. I modified my Alfred workflow and added an expiration time (5 minutes, 1 hour, 1 day, 1 week), then set up a job using launchd that would delete the rule after the specified time.

And this worked really well for a bit! It solved the problem simply. But it bothered me that if my computer was closed or disconnected from the internet, the rule might be deleted later than I intended. Blip was born.

Beyond Self-Destructing Firewalls

The self-destructing firewall feature is useful on its own. It works really well and solves the problem elegantly. Also having one place to add rules to your servers regardless of their provider is also really handy, no more logging into multiple dashboards.

As I was building it out, I found some additional key features that are worth implementing:

IP Whitelist Scheduling

There was a time in my life when I worked from a WeWork consistently and what I wouldn't give for this feature. This allows you to specify which IPs should be whitelisted on which port for which servers at what times. For example: should have access to personal-site on port 22 from 9am - 5pm Monday - Friday.


I modeled the Teams feature very closely after Laravel Forge's Circles. It doesn't require you to make specific teams, but rather just allows you to invite others to manage specific resources. So for instance, if I was working with another developer on a client project, I would invite them to join just that specific server and allow them to whitelist IPs from their Blip account. It's simpler than a conventional Teams feature and allows much more flexibility.

Secure Sharing

One of my favorite 1Password features is the ability to securely share anything in your vault whether or not the other user has 1Password. I want to bring this same ease to Blip. If you needed to give someone temporary access to one of your servers without them having to set up a Blip account, you can.

Why would you want to share access to a server with someone? An example:

Let's say you have a staging site, and you've specified that only certain IPs can view it (you've locked down ports 80 and 443). You need a client to view the site, but only from their IP and only for an hour.

You can share a secure link directly from your Blip account that is tied to their email address. Once they verify their email and accept the share, Blip automatically detects their current IP address, adds it to your specified server for ports 80 and 443, then removes the rule after an hour.

You don't need to coordinate with them to get their IP address and you don't need to remember to remove access afterward. Blip does all of the heavy lifting for you.

IP Sync

If you use a service that regularly needs access to your servers and keeps a public list of IP addresses they SSH in from, this feature is for you. For me, those services are commonly the indispensable Forge and Envoyer. I keep a separate security group just for their IP addresses that I update whenever they add or remove IPs from the list.

Fortunately, they keep this list of IP addresses in a text file that is publicly accessible. So we can utilize Blip to keep these in sync with your security group. Blip will check once a day and update your group with any changes.


One of my requirements for building out Blip was integrating with tools that I (and many other people) already use on a daily basis. So along with the site, I'll be rolling out an Alfred workflow, a Raycast extension, and a CLI tool so that you can talk to Blip right from your machine.

Wrapping Up

I'm really excited to launch Blip, I think it will be a game changer for many developer workflows. Sign up on the homepage to be notified when we launch!

(Excellent) syntax highlighting provided by Torchlight