lissy93/networking-toolbox: 100+ Offline Networking Utilities in One SvelteKit App

What Networking Toolbox Actually Replaces

The problem is tab sprawl. A sysadmin debugging a subnet mask, a CIDR range, a JWT, a MAC address vendor prefix and a TLS certificate chain typically opens five different websites, several of which want an account or ship the input to a server. The README describes Networking Toolbox as "the all-in-one offline-first networking toolbox for sysadmins", and the topics list on the repository adds docker, network-analysis, network-security, offline-capable, self-hosted and sysadmin.

The audience is narrow and specific. It is for people who already know what a /26 is and want to stop reaching for a search engine to compute one. It is not a teaching tool, and the README does not present it as one. The value proposition is proximity: everything sits behind one URL, one search box and one theme, and the browser does the arithmetic locally.

The offline-first claim is the part worth taking seriously. Because the app is built with Svelte and SvelteKit and the README states it has "zero third-party dependencies" at runtime, the deployed artifact is a bundle of static assets plus client-side code. That is what makes a self-hosted copy useful on an isolated management VLAN where outbound DNS is blocked.

How the Offline-First Architecture Works

The repository layout tells most of the story. There is a src/ directory, a static/ directory, a swagger.yaml, a start.js entry point and a SvelteKit config. The build is driven by Vite, and the deployment target is chosen by an environment variable rather than by branching code.

The mechanism is the SvelteKit adapter system. The README lists seven deployment options, and they are not seven codebases: the same source is compiled against adapter-node, adapter-static, adapter-vercel, adapter-netlify or adapter-auto depending on the DEPLOY_ENV value. Setting DEPLOY_ENV to node produces a Node server; setting it to static produces a directory of files you can drop on any web server. That single switch is the most interesting design decision in the project, because it means the offline story is not a separate product from the hosted one.

The presence of swagger.yaml and a dedicated API test script (test:api) indicates there is an HTTP surface beyond page rendering, but the README does not document the endpoints. Treat swagger.yaml as the source of truth if you need to call the app programmatically; the prose documentation does not cover it.

On the client side, the feature list mentions custom layouts, theming, bookmarking and multi-language support. Those are browser-local concerns, which is consistent with a build that can run with no server at all.

Installing Networking Toolbox with Docker

The fastest path is the published image. The README gives a single command, and the port is fixed at 3000 in the example.

docker run -p 3000:3000 lissy93/networking-toolbox

After it starts, open http://localhost:3000. The README does not state a startup delay, so if the page does not load immediately, check the container logs rather than assuming the image is broken.

For a persistent deployment, the repository ships a docker-compose.yml. It pins the image to lissy93/networking-toolbox:latest, sets NODE_ENV, PORT and HOST, and adds a healthcheck against /health.

services:
  app:
    image: lissy93/networking-toolbox:latest
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - PORT=3000
      - HOST=0.0.0.0
    restart: unless-stopped

One caveat worth flagging before you copy that file: the healthcheck in docker-compose.yml runs wget against http://127.0.0.1:3000/health, and the Dockerfile comment says "Optional: add a lightweight health endpoint in your app (e.g., /health)". The word optional suggests the endpoint may not exist in every build. Verify it responds before you wire the container into anything that restarts on unhealthy status.

If you would rather build from source, the README's development steps are git clone, cd, yarn, yarn dev. The project uses Yarn for setup in the README but npm scripts in package.json, and both are present in the repository, so either package manager is workable.

Static and Serverless Deployment Options

The Docker path gets the attention, but the static build is the one that matches the offline-first pitch. Run npm run build:static, which sets DEPLOY_ENV to static, and upload the contents of ./build to any web server or CDN. The README explicitly says "any web server, CDN or static host".

There is also a GitHub Pages route that requires no local toolchain: fork the repository, trigger the "Deploy to GitHub Pages" workflow from the Actions tab, then set Settings > Pages > Source to the gh-pages branch. The resulting URL follows the pattern https://<your-username>.github.io/networking-toolbox/.

For platforms that are neither static nor plain Node, the README documents a generic escape hatch. Set DEPLOY_ENV to one of vercel, node, docker, netlify, static or auto and build.

DEPLOY_ENV='node' npm run build

The auto value lets the adapter-auto package decide, which is convenient for a first deploy and less convenient when you want a reproducible artifact. For anything you intend to keep, name the target explicitly.

What the README does not document is a rollback procedure, a version pinning policy for the Docker image, or a migration path between releases. If you self-host, tag your images yourself rather than tracking latest.

Where Networking Toolbox Is the Wrong Tool

The name invites a category error. A toolbox of browser-side calculators is not a packet analyzer, a port scanner or a monitoring agent, and nothing in the README claims otherwise. If your task is capturing traffic on an interface, correlating flows over time, or continuously polling device state, this project has no mechanism for it. There is no mention of a capture library, a scheduled job, or a background worker in the repository files.

The second limitation is scope. The tool set is whatever the maintainer has built and merged. There is no plugin API described in the README, no documented way to register your own utility, and no configuration file for enabling or disabling individual tools. If your team needs one specific conversion that is not in the catalogue, your options are to contribute it upstream or run something else alongside.

The third is trust surface. Offline-first means the computation happens in your browser, which is good for confidentiality, but it also means correctness depends on the implementation rather than on an authoritative server. For anything where a wrong answer has consequences, such as generating a certificate or validating a config before it reaches production, cross-check the result. The README provides no accuracy statement, no test vectors and no comparison against reference implementations.

Finally, the project is a single-maintainer repository with an MIT licence and a copyright line naming Alicia Sykes. That is a normal shape for a utility collection, but it means bus factor is one, and the README does not describe a governance model or a release cadence commitment.

How It Compares with Running Separate CLI Tools

The obvious alternative is the tools you already have: ipcalc or sipcalc for subnet arithmetic, dig for DNS, openssl for certificate inspection, jq for payload work, plus a browser bookmark folder for the rest. That approach is more precise. Each tool is a specialist, each has its own test suite and its own documentation, and you can script them in a pipeline.

The difference in approach is where the work happens. Command-line tools run in your shell, on your machine, and compose with other commands. Networking Toolbox runs in a browser tab and does not compose with anything: there is no documented CLI, and the README's only interface is the web app. You cannot pipe output from one utility into another.

What you get in exchange is uniformity. One install covers every tool, the interface is consistent, theming and bookmarking are shared, and the whole thing works on a phone. For an engineer who needs a subnet calculator twice a week and does not want to remember sipcalc flags, that trade is reasonable. For an engineer writing a deployment script that derives CIDR blocks automatically, it is the wrong shape entirely.

A self-hosted internal wiki with a page of bookmarks is the other alternative, and it is worse in every dimension except one: you control exactly which tools are listed. Networking Toolbox does not offer that control.

Licence, Maintenance and Upgrade Cost

The repository is licensed under MIT, and the README's footer repeats that, crediting Alicia Sykes with a 2026 copyright. MIT is permissive: you can use, modify, redistribute and self-host the code, including in commercial settings, provided you keep the copyright notice and licence text. That is a summary of the licence, not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation.

The practical implication for a self-hosted deployment is that forking is a legitimate option. If you need a tool the project does not ship, or you want to strip the catalogue down, the licence permits it. The cost is that you now own a fork.

On maintenance, the facts are these: the repository is not archived, and the last push was on 2026-04-05. The most recent release listed is v1.6.0 from 2025-11-16, preceded by v1.5.0 on 2025-10-25 and v1.4.0 on 2025-10-22. Two releases three days apart followed by a month-long gap suggests the release timing is driven by fixes rather than a schedule. There is no stated support window, no LTS branch and no documented deprecation policy.

Upgrade cost is low if you use the container, since the image is the unit of change. It is higher if you build from source, because the toolchain moves: the Dockerfile pins node:22-alpine, and package.json tracks SvelteKit 2.x, Vite, Vitest 3.x and Playwright 1.x. The repository includes an .nvmrc, so read it before choosing a local Node version. There is also a hold-my-beer script that chains format, lint, types, check, build-check and test, which is a reasonable gate to run before merging your own changes into a fork.

Editorial conclusion

Adopt it if you want a client-side reference and calculator set that runs from a container or a static host, and if you can accept that the tool catalogue is defined by the repository rather than by you. Do not adopt it as a replacement for Wireshark, nmap or a monitoring stack; it does not do live capture or continuous polling. Before rollout, verify two things on your own build: whether the /health endpoint the Dockerfile and docker-compose.yml probe actually returns 200, and whether the tools you need are present in the version you pin, since the README does not publish a tool index.

Frequently asked questions

Official sources

1. License: MIT
2. lissy93/networking-toolbox on GitHub
3. Project website
4. README
5. Releases