Every company has a version of this problem.

A new engineer joins. Someone sends a Slack message to whoever manages the servers. That person sets up access when they find the time - creating accounts, copying keys, updating permission files. All done by hand, all from memory. When that engineer leaves, most of this gets undone. Some of it doesn’t - old access quietly lingers on servers nobody thinks to check.

Some teams give up and share a common deploy or ubuntu user. One SSH key, everyone uses it. Fast to set up, impossible to audit. When something breaks in production - or something gets deleted - you have no idea who was logged in. The logs say ubuntu. That’s where the investigation ends.

The drift nobody notices

The manual approach creates drift quietly. Keys that should have been removed are still there. A contractor who left six months ago can still log in. Nobody knows exactly who has access to what because it lives scattered across the configuration of individual servers, not in any one place you can actually look at.

You only find out how bad it is during a breach, an audit, or a compliance review.

Where the idea came from

I worked at Yahoo from 2005 to 2007. One of the internal tools we used was yinst - a package manager built for Yahoo’s massive server fleet. Among other things, it handled adding and removing users across servers. One command, right setup, clean removal.

I didn’t think much of it at the time. That was just how things worked at Yahoo.

Years later, building and managing infrastructure at smaller companies, I kept noticing the absence of it. The manual approach isn’t wrong exactly - it works fine when the team is small and careful. But it doesn’t scale with the team, and it has no memory. When someone leaves or an audit arrives, you’re reconstructing history from Slack messages and gut feel.

addy is my attempt to bring that same idea - one command, predictable outcome, Git as the record - to teams that don’t have a hundred infra engineers to build it from scratch.

What addy does

addy treats server access like a package. Your team’s SSH public keys live in a Git repository. addy reads from that repository and applies changes to your server.

sudo addy install user/alice   # creates Linux user, installs SSH key
sudo addy install sudo/alice   # grants passwordless sudo
sudo addy remove sudo/alice    # revokes sudo
sudo addy remove user/alice    # removes access entirely

No database. No service to run. No web interface to maintain. Just a Git repo and simple commands.

When someone joins, you add their public key to the repo and run one command. When they leave, you remove the key and run one command. Their access is gone - cleanly, completely, verifiably. No shared users. No drift.

Why Git is the right place for this

Git gives you two things that matter here.

The first is workflow. Instead of sharing public keys over Slack and hoping someone copies them correctly, engineers open a pull request to add their key to the repository. The team can review it, the change is visible, and there’s a clear record of when it was merged.

The second is audit trail. Every key addition and removal is a commit. When a compliance team asks “show me every access change in the last six months,” you have an answer - not a pile of Slack threads to go through.

The actual granting of access - creating the user on the server, installing the key, updating permissions - still happens through addy commands. That part isn’t automatic. But because the keys live in Git, the record of who should have access is always in one place, versioned, and reviewable.

The setup

pip install addy

sudo addy config set git-repo git@github.com:your-org/ssh-keys.git
sudo addy install user/alice

Your key repository needs one thing: a users/ directory with .pub files named after each person.

users/
  alice.pub
  bob.pub
  charlie.pub

addy handles creating the Linux user, installing the key to the right location, setting correct file permissions, and validating the key format before doing any of it. For sudo access, it writes a sudoers file and validates it with visudo - so a malformed entry doesn’t accidentally lock you out.

Who this is for

Teams of 5 to 50 people. Big enough to have real access management overhead. Small enough that nobody has built internal tooling for it yet.

If you’re managing server access through Slack messages and shared users, addy is worth an hour of your time.

The alternative is finding out - during an audit or after an incident - that you don’t actually know who has access to what, and no log to help you figure it out.

github.com/abhinavs/addy