IT-Tools self hosted or a local extension: what a small team should run
The Docker command is one line. The upkeep is not, and a browser-local toolbox gets most teams the same privacy with nothing to host.
Running IT-Tools self hosted is easy: the project publishes a Docker image and a one-line run command. The harder question for a small company is whether anyone should own that container at all, when a free local tool like AyeTab gives each developer the same kind of toolbox with nothing to deploy.
What self-hosting IT Tools involves
IT Tools is an open source collection of developer utilities, released under GPLv3 and maintained on GitHub. Its README shows two images, one on Docker Hub and one on GitHub's container registry, and a command along these lines:
docker run -d --name it-tools --restart unless-stopped -p 8080:80 corentinth/it-tools:latest
The same README points homelab users to Cloudron, Tipi and Unraid as other routes. For an engineer, that is ten minutes of work. For an operator, it is the start of a small, permanent line item.
The costs nobody puts in the ticket
A self-hosted tool looks free until you list what comes with it:
- A host. Somewhere for the container to live, with the access controls you would expect for anything internal.
- Updates. Someone has to pull new images and decide when to move off a pinned version.
- Access. Remote staff need a VPN, a tunnel or an auth proxy to reach it.
- An owner. When it breaks during an incident, someone has to know it exists.
None of this is heavy. It is just one more thing, and small teams tend to collect those.
The local alternative
AyeTab takes the other route. It is a free Chrome extension that turns the new tab page into a set of developer tools, with a side panel for using them next to another page and a web app at app.ayetab.com for anyone who will not install an extension. The input stays in the browser: nothing is uploaded, and no account is required. Once installed it works offline.
For an operator, that changes the shape of the problem:
| Question | IT Tools, self hosted | AyeTab |
|---|---|---|
| What do we run? | A container and its host | Nothing |
| Who patches it? | Your team | Chrome updates the extension |
| Where does pasted data go? | Your server | Stays in each person's browser |
| Remote access | VPN or proxy needed | Works anywhere, offline too |
| Can we change the code? | Yes, it is open source | No |
| Cost | Free software, plus hosting time | Free |
The privacy outcome is similar in both cases, which is usually why teams self-host in the first place: they do not want tokens or customer payloads pasted into a public site. AyeTab reaches that outcome without the server.
When self-hosting still wins
Keep IT Tools on your own infrastructure if you need a shared URL for people who cannot install browser extensions, if your policy requires software you can audit and build yourself, or if you want to add internal tools to the codebase. Those are real reasons, and the project makes them easy to act on.
A simple rollout
For most small teams the lighter path is enough:
- Share the AyeTab Chrome Web Store listing in your engineering onboarding doc.
- Point people without the extension to the web version of the tools.
- Tell the team the rule you care about: decode tokens and format payloads in a local tool, not on a random website.
That gives you the toolbox and the privacy story with nothing on the infrastructure list. If a hard requirement later pushes you toward self-hosting, the Docker command above still works.