返回资讯中心
外部精选
大数据
#数据科学#机器学习

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 loca…

KDnuggetsNahla Davies2026/10/20 · 6 天前18 分钟阅读

以下正文同步自 KDnuggets,版权归原站所有,已转换为易读排版。

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.

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.

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.

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.

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.

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.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →