IT Tools: Self-Hosted Dev Utilities, No Privacy Trade-Off

I run IT Tools self-hosted on every operations VPS I touch, for the same reason I run a self-hosted password manager rather than pasting credentials into a random web form. The list of daily developer utilities (JWT decoder, hash generator, JSON formatter, regex tester, base64 encoder, UUID generator, cron parser) is the same on every dev’s screen, and the inputs to those tools are usually the things you least want a third party to log.

The hosted version at it-tools.tech is excellent. The maintainer has been clear that everything runs client-side. I trust that. What I trust less is the long tail of look-alike utility sites that copy the UX, get traffic from a few SEO posts, and quietly send every JWT you decode to a logging endpoint. I’ve audited two agencies where engineers had bookmarked one of those clones for years before anyone questioned it.

This post is the small, boring stack I actually run: one container, one reverse proxy entry, optional basic auth, done in about ten minutes. If you’ve ever caught yourself thinking “I’ll just paste this token into the first JWT decoder in Google for a sec,” this is the cure.

What IT Tools actually gives you

The project is a single Vue app with a side panel of categorised utilities. The categories I reach for weekly:

• Crypto: JWT decoder, hash text (MD5, SHA-1/256/512), HMAC generator, bcrypt hash, RSA key pair generator, password strength analyser.
• Converters: JSON to CSV/YAML/TOML, base64 file encoder, URL encoder, HTML entity escaper, colour-format converter.
• Web: URL parser, user-agent parser, HTTP status code reference, MIME type lookup, Open Graph meta inspector.
• Text: regex tester, lorem ipsum, slug generator, diff viewer, case converter, line-break and whitespace cleaner.
• Generators: UUID v4, ULID, BIP39 mnemonic, Lorem Picsum URLs, QR codes, Wi-Fi QR codes.

The complete list sits at over 80 tools and grows roughly monthly. The maintainer (Corentin Thomasset) accepts community PRs, and the project has been steady for years rather than chasing trends.

What you don’t get: anything server-side. No API mode, no rate-limiting, no audit log. That’s deliberate. IT Tools is a frontend-only static bundle served by Nginx inside the container.

The deployment stack

Three pieces, two of which you probably already have on the VPS:

1. Docker engine, installed from the official Docker repository (never from apt’s default repo or a third-party install script).
2. Nginx Proxy Manager (or Traefik, or Caddy — anything that terminates TLS and lets you bolt on basic auth).
3. The IT Tools container itself.

If you don’t yet have a hardened host to deploy on, start with the Linux server security fundamentals post and come back. I won’t help debug an instance that’s running on an unpatched, root-SSH-enabled VPS.

For the proxy layer, the Portainer + NPM + Vaultwarden post is the canonical setup I deploy alongside this. Same NPM container fronts every internal tool I run.

The Compose file

This is the entire IT Tools deployment:

services:
  it-tools:
    image: corentinth/it-tools:latest
    container_name: it-tools
    ports:
      - "8080:80"
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

Bring it up:

docker compose -f /srv/docker/it-tools/docker-compose.yml up -d

The container exposes port 80 internally; I map it to 8080 on the host so it doesn’t fight Nginx Proxy Manager for port 80. If the box only runs IT Tools (uncommon for me, but reasonable), you can map straight to 80 and skip the proxy entirely on a private network.

The Watchtower label is there because every container I run on shared infrastructure is auto-updated on a 24-hour interval. The Watchtower setup is documented in the Uptime Kuma post — same pattern, same labels.

The proxy entry

In Nginx Proxy Manager, add a Proxy Host pointing tools.yourdomain.com (or tools.internal if you only resolve it inside a VPN) to http://it-tools:80. Request a Let’s Encrypt certificate, force SSL, enable HTTP/2.

For anything that’s reachable from the public internet, add basic auth in the NPM “Access Lists” panel before you tell anyone the URL exists. The reason is in the next section.

Why a public IT Tools instance is a bad idea

The tools themselves are harmless. They run in the visitor’s browser, they don’t store anything, they don’t have an admin panel. So why bother with auth?

Because a public IT Tools instance under your domain becomes a phishing-grade asset. An attacker can clone the page, swap your tools.yourdomain.com URL into a phishing email (“decode this JWT to confirm your account”), and the victim sees a familiar URL on a familiar brand that does serve a real-looking utility. Some of those tools (the QR code generator, the Open Graph inspector, the URL parser) are exactly the kind of thing a phishing flow could legitimately link to as part of an “account verification” pretext.

I’ve never seen this exact attack in the wild against a self-hosted IT Tools deploy. I’ve seen the same pattern against self-hosted PDF converters and self-hosted code playgrounds. The mitigation costs five minutes (basic auth in NPM, or a VPN-only DNS record) and removes the category entirely. Pay the five minutes.

For internal-only deployments, my preferred pattern is to put it behind Authentik for SSO, or to make the DNS record split-horizon so it only resolves inside the VPN. The WireGuard Easy and Mistborn posts cover both ends of that spectrum.

What I use IT Tools for, day to day

The five tools I open more than once a week:

• JWT decoder: every time a customer sends “the API returns 401, here’s the token from devtools.” Decode locally, verify the exp, check the issuer claim, return the actual answer.
• Hash text (SHA-256): generating fingerprints for config files, comparing build artefacts between environments, sanity-checking webhook signatures.
• Regex tester: the one I avoided learning for years and now use weekly. The visual match-highlighting beats grep -E for anything non-trivial.
• JSON to YAML / YAML to JSON: the silent productivity gain when you live between Kubernetes manifests, GitHub Actions workflows, and Terraform locals.
• Cron expression parser: because I will never trust my mental parser of 0 */6 * * * over a tool that explicitly tells me “every 6 hours.”

What I deliberately don’t use it for: anything that needs an audit trail. If a customer ticket requires “show me what you decoded and when,” that goes in a logged internal tool, not a frontend utility. IT Tools is the engineering-bench equivalent of a calculator app, not a system of record.

Pairing it with the rest of the stack

IT Tools fits naturally next to the other operations utilities I deploy on the same small VPS:

• Uptime Kuma for monitoring the rest of the fleet.
• Code-server for the in-browser VS Code I use when I’m on a Chromebook or a borrowed machine.
• Cryptgeon for the moments when I do need to send a secret to a customer; IT Tools handles the local manipulation, Cryptgeon handles the transmission.
• n8n for any utility that genuinely needs to be a workflow rather than a one-shot tool.
• Stirling PDF for the document-conversion category, which IT Tools deliberately doesn’t touch.

Five containers, one VPS, one purpose: keep day-to-day engineering work off third-party utility sites.

Closing the loop

IT Tools is the smallest deployment in the stack and the one I appreciate most often. Every time I catch myself about to paste a JWT into Google’s first organic result, the muscle-memory now ends at tools.<my-domain> instead. Ten minutes to deploy, roughly zero euros per month to run, and one less category of “did I just leak something?” thought at the end of a long day.

If you only adopt one self-hosted utility from the broader operations-automation catalogue, this is the cheapest one to justify and the easiest one to keep running.