Our internal tools don’t have a login screen

It is the age of customized software, and within our team, we’re shipping more self-built internal tools than ever. Most of the time, it’s way easier (and cheaper) to build a tool ourselves exactly the way we want it rather than sign up for yet another subscription.

This isn’t a new concept for us, but the amount that we’re shipping isn’t something we’ve been able to do before. And I think part of the reason we’ve been able to use this so effectively is how easy we can share the apps internally without exposing anything to the open internet, or even needing people to log in.

This post is about how that works, and what it looks like in some of the real tools that we’ve built. Let’s get into it!

how we used to share apps

Usually when we built tools in the past, we would build some sort of Google log in screen. People would then be able to log in with their company email SSO to get access to the app.

However, this definitely presented a few problems. Firstly, we generally prefer to test apps on our team internally before opening it up to the wider company. Unless you’re manually setting emails, there’s not really a good way to limit SSO to a single team. So what ended up happening was the team would just locally clone the GitHub repo and work from there.

But this meant pulling and starting the app every time you wanted to access it, which was honestly very annoying. For larger projects it was fine, but to quickly share feedback or ideas, it was sometimes more work to get someone onboarded to the app than building it was.

Second, it meant we had to do all the security features and things that came with having a website on the internet that someone could potentially hack to get access to. The security team owned the login, which made it hard for our team to debug locally ourselves.

All possible to work arround, but annoying.

what happens now

Everyone in our company is in the NetBird NetBird org, and everyone in our team is part of the Growth group. We have a mac mini that runs all of our internal apps, and a policy set up so that everyone in the Growth group can access it.

Within NetBird, we can then set custom domains or additional access rules for any different services that we run on our mac mini. So for example our sticker design app is running on the mac mini on port 3030 , which is accessible through sticker.netbird.us, and anyone in Growth or Sales NetBird internal group can access it.

As long as I’m connected through my NetBird account, I can access any of the websites and it automatically auths my user WITHOUT me having to log in, which is so so cool. If I’m not connected, then I can’t even get on the page. There’s no login screen at all.

The connection is made through a direct, encrypted WireGuard tunnel, meaning no open ports that could give attackers access to our services.

case study: The Sticker App

Edward’s built most of the new apps. Some of them have been a bit silly, like an engagement leaderboard for our social media channels, and some of them have been extremely helpful, like Issuemaxxing, which helped us handle over 800 issues.

The sticker app is somewhat in-between fun and useful. We wanted a way to create new sticker designs, vote and comment on the best ones as a team, and drop inspo for any later rounds.

Edward said, “Hold my redbull,” and sticker app was born in just an afternoon.

sticker.netbird.us will only return the webpage if the device is connected and authenticated with NetBird, and has the correct permissions to view the site. Otherwise it’ll return an unauthorized code. The app will pull the user’s name from the NetBird connection, and use that to label any comments, posts, likes or dislikes they make on the app.

This is zero trust in practice. Every request must be checked against the access policies before it reaches the service. Only people who’s devices have been given access can get to it, which means the blast radius is a lot smaller if any devices did get compromised.

The webpage is loaded in less than a second without any sort of app login to do, which as a user, makes it super nice for me. It’s made it so much easier to quickly build apps like this to collaborate and share internally without worrying about Google SSO or securing exposed login pages.

to conclude

You can find more about setting this up with bringing your own proxy and authentication, or if you’re just getting started, check out this guide!

I really think personalized tools and software is going to become more and more mainstream as AI coding becomes more accessible. But I also think security vulnerabilities are going to be more and more of a problem. We’ve already seen PHP, OpenCode, Railway, LiteLLM, and dozens more in the past week.

Which is why, imo, anything you don’t have to expose should be exposed. Especially internal tools that no one outside of the company needs to access.

If you’ve built any cool internal apps for your team, definitely reach out, I’d love to hear about them :)