5 Docker Containers for Devs
Five self-hosted Docker containers replace the public utility sites where developer data quietly leaks. Learn which ones handle JWT decoding, data transformation, file conversion, API testing, and diagram rendering locally.

The task is small. A JWT needs decoding, a log field is Base64 inside gzip inside hex, or a client sent a HEIC screenshot and the ticket wants a PNG. The fastest route is the third search result, a utility site with a paste box and an ad banner. That is where the token, the log line, and the screenshot end up. Nobody planned to hand internal data to a stranger's web server. It happened because the alternative was fifteen minutes of setup for a five-second job.
Five containers close that gap. Each one is a small local service that does a recurring developer chore on your own machine: inspect, transform, convert, test, and diagram. None of them is AI infrastructure, and none overlaps with the agentic developer containers KDnuggets covered earlier. Boring utilities are the point here.
| Container | Use It For | Local Advantage | First Caution |
|---|---|---|---|
| IT-Tools | Inspect: JSON, JWT, Base64, hashes, UUIDs, regex, cron | One local app instead of a trail of utility tabs | Convenience layer, not a secret store or a test suite |
| CyberChef | Transform: chained decode, decompress, hash, re-encode | Saved recipes make the chain repeatable and shareable | Decodes the bytes; does not vouch for what they contain |
| ConvertX | Convert: images, documents, e-books, SVG, video, 1,000+ formats | Files never leave the machine; accounts and auto-delete built in | Untrusted files stay untrusted; claim the first account at once |
| Hoppscotch CE | Test: requests, collections, environments, request history | Workspace lives next to the project, not in a browser profile |
Three services plus Postgres; .env and history hold secrets
|
| Kroki | Diagram: PlantUML, GraphViz, D2, Structurizr and more from text | Diagrams as code, rendered with no hosted service | Add companion images only for syntaxes a project actually uses |
1. IT-Tools: The Everyday Dev Toolbox
IT-Tools is a single web app holding the small utilities developers otherwise search for one at a time: JSON formatting and comparison, JWT decoding, Base64 in both directions, hash generation, UUIDs, regex testing, cron expression helpers, and color and date converters. The self-host route is one command:
docker run -d --name it-tools --restart unless-stopped -p 8080:80 corentinth/it-tools:latest
Open localhost:8080 and the whole grab bag is there, on a machine you control — and that is the entire pitch. Nothing about IT-Tools is clever, and it doesn't need to be, because the problem it fixes is a browser history full of decoder sites. Treat it as a convenience layer, though. Nothing you paste into it is stored with any care, so it is not a vault for secrets, and decoding a token there tells you what the token says about itself, not whether your server would accept it.
2. CyberChef: The Data Transformation Bench
Some blobs need more than one operation. A log field arrives as hex, which decodes to gzip, which decompresses to JSON with a UTF-16 string inside. CyberChef, built by GCHQ, exists for exactly this chain. You drag operations into a recipe — Base64 and XOR at the simple end, AES and character-set conversion further along — and the recipe re-runs every time the input changes. GCHQ publishes a ready image, ghcr.io/gchq/cyberchef:latest, which serves the app on port 8080.
The recipe, not any single operation, is what you keep. From Hex, then Gunzip, then Decode text as UTF-16, then JSON Beautify is a four-step sequence that can be saved, reloaded, and shared as a URL. The next person who meets the same field then runs the same steps. Breakpoints pause the chain between operations so the intermediate bytes can be inspected, and the Magic operation guesses at nested encodings when the input is a mystery. The app is entirely client-side, which is why it runs in a container with no backend at all.
If the blob came from an incident, a customer file, or an internal token, do you want it in an unknown site's paste box? Running CyberChef locally makes that question go away, though it does not vouch for the data. A successful decode shows what the bytes contain, not whether the content is true, complete, or safe to act on.
3. ConvertX: The File Converter You Control
File conversion is the clearest case for pulling a utility off the public web, because files carry more than the thing you wanted converted. ConvertX doesn't convert anything itself. It puts one upload page in front of tools you have probably installed and forgotten: FFmpeg for video, ImageMagick for images, LibreOffice and Pandoc for documents, Calibre for e-books, Inkscape for vectors — and the README counts more than a thousand formats between them. The documented deployment is a short Compose file: the ghcr.io/c4illin/convertx image on port 3000, a JWT_SECRET value, and /app/data mounted to a local folder. The data mount is what lets uploads and results survive a restart. Accounts and password protection come with it, and the default cleanup job removes converted files after 24 hours — which is the right default for a tool that sees screenshots of other people's bugs.
The jobs it takes over are the ones that never quite justify a proper tool. A HEIC screenshot has to become a PNG before the bug tracker will accept it. Someone's spec arrived as DOCX and the docs live in Markdown. The ticket system wants the screen recording in a format it recognizes. Not one of those files ever leaves the machine.
One honest caveat: local does not mean safe. The converters inside ConvertX parse whatever they are fed, so an untrusted file is still an untrusted file, and the service should stay on localhost or behind real authentication. The README is explicit about the first-run window too. Anyone who reaches the page before you create the first account can register it, so create yours immediately and leave ACCOUNT_REGISTRATION at its default of off.
4. Hoppscotch: The API Tester That Lives With the Project
Hoppscotch is an API workspace: requests, collections, environments, and variables, with a history that persists between sessions. The hosted version is fine for a one-off call. Running the Community Edition locally makes sense when API work repeats, because the collections and environments then live next to the project rather than in someone's browser profile.
Budget an afternoon for the setup, because this is the heavy one. Hoppscotch CE wants a Postgres database you provide, then either three containers (frontend on 3000, backend on 3170, admin on 3100) or the all-in-one image that bundles them. Before anything starts you write a .env with the DATABASE_URL, a 32-character DATA_ENCRYPTION_KEY, and the origins allowed to talk to the app, and the first login only works after the Prisma migration has run against that database. Hoppscotch CE is a small stack rather than a toy container.
The decision rule is simple: if you test one endpoint once, use the hosted app or curl. If the same API gets exercised every week, the local workspace pays for its setup. Either way, the environment file and the request history contain credentials and internal hostnames, so they get the same handling as any other project secret.
5. Kroki: Diagrams as a Local Service
Kroki turns text into diagrams over HTTP. POST a PlantUML or Graphviz source to the gateway and an SVG comes back; D2, Structurizr, Ditaa, and about twenty other syntaxes work the same way. One container, yuzutech/kroki on port 8000, carries all of those renderers already installed, which used to mean setting up Java and Graphviz by hand. Mermaid, BPMN, Excalidraw, and diagrams.net need their companion containers running alongside the gateway.
The habit it supports is diagrams as code. An architecture sketch stored as .puml next to the source gets reviewed in the pull request, rendered in the docs build, and regenerated when the system changes — with no hosted renderer in the loop. Start with the gateway alone and add a companion image only when a project uses that syntax. Every extra container is another image to update.
Keep the Utility Stack Small Enough to Trust
The five jobs are inspect, transform, convert, test, and diagram. Start with IT-Tools plus whichever of CyberChef or ConvertX matches the chore you did last week. Add Hoppscotch when API testing becomes a routine rather than an event, and Kroki when the second diagram needs updating.
When two of these need to talk, describe them in one Compose file. Compose puts every service on a shared default network where each one is reachable by its service name. A URL such as http://kroki:8000 therefore works from another container without an IP address. Named volumes hold ConvertX's data and Hoppscotch's database, which is the difference between "tried this once" and "recreated it next month."
Pin image tags for anything a team relies on, and stop the containers nobody has opened in a month. Keep all five off the public internet unless one has been deliberately secured. The earlier KDnuggets article on practical Docker configurations covers the tuning once the stack is stable.
A paste box is a fine tool. The one on your own machine is the one to use.
Nahla Davies is a software developer and tech writer. Before devoting her work full time to technical writing, she managed—among other intriguing things—to serve as a lead programmer at an Inc. 5,000 experiential branding organization whose clients include Samsung, Time Warner, Netflix, and Sony.