Networking Toolbox: an offline-first SvelteKit app for 100+ network utilities

The gap Networking Toolbox fills: a private reference for network arithmetic

Sysadmins juggle a lot of small, repetitive questions. What is the broadcast address for this CIDR block. What does this MAC prefix belong to. Does this cipher string match this policy. Most people answer those with a search engine and whichever ad-heavy calculator ranks first, which means typing internal addressing details into someone else's form. Networking Toolbox is positioned against exactly that habit. The README calls it "the all-in-one offline-first networking toolbox for sysadmins" and groups the tools under converting, calculating, diagnosing and verifying server configs. The intended user is someone who already knows what a subnet mask does and wants the answer without a round trip to a third-party site. The offline-first framing is the actual product claim here, not the tool count.

SvelteKit with adapter selection instead of a fixed server target

The stack is Svelte plus SvelteKit in TypeScript, and that choice explains most of the deployment behaviour. SvelteKit builds are adapter-driven, so the same source tree can emit a Node server, a static bundle or a platform-specific output. The project exposes that through a single environment variable. Setting DEPLOY_ENV to one of vercel, node, docker, netlify, static or auto and then building produces the matching artifact. The README gives DEPLOY_ENV='node' npm run build as the worked example. The practical consequence is that the utility logic has to run in the browser, since a static build has no server to call. That is consistent with the offline-capable claim and with the README's statement of zero third-party dependencies. It also means the app cannot do anything that requires a privileged socket, which shapes what the tools can and cannot be.

Six documented ways to get it running, from one docker run to a GitHub Pages fork

The fastest path is the published image: docker run -p 3000:3000 lissy93/networking-toolbox, with an example docker-compose.yml linked from the repository. Building your own image is a two-step variant: docker build -t networking-toolbox . followed by docker run -p 3000:3000 networking-toolbox. For a Node deployment from source, the README says to run npm run build:node and then start the server with node build. A static deployment uses npm run build:static and expects you to upload the contents of ./build to any web server or CDN. There is also a GitHub Pages route: fork the repo, trigger the "Deploy to GitHub Pages" workflow from the Actions tab, then set Settings > Pages > Source to the gh-pages branch. Cloud hosting is the vaguest option, described only as forking and importing into Vercel, Netlify or a static provider. Local development is git clone, cd, yarn, yarn dev, with Node.js, Git and optionally Docker as prerequisites. Note the inconsistency in the documentation: the setup block uses yarn while the project command list uses npm run variants, and both are presented without comment on whether they are interchangeable.

What the test and check commands imply about upgrade cost

The README states that before merging, code must pass unit and end-to-end tests plus linting, type checks, svelte check and build checks. The commands behind that are yarn test, with narrower targets npm run test:api for API tests, npm run test:e2e for Playwright end-to-end tests and npm run test:coverage for coverage. Static verification runs through npm run check for SvelteKit types and diagnostics, npm run types for strict TypeScript checking, npm run lint for ESLint across TS and Svelte files, npm run format for Prettier and npm run build-check to confirm the build works. For an operator rather than a contributor, the relevant part is that npm run build-check exists as a single gate. If you pin a version and later bump it, that command plus yarn test is the documented way to confirm the tree still builds before you redeploy. The release cadence visible in the supplied material is three tagged releases between October and November 2025, including v1.6.0, which suggests active but not frantic maintenance. Nothing in the material describes a migration path or breaking-change policy between minor versions, so treat version bumps as something to verify rather than assume.

Offline-first is a boundary, not a feature list

The strongest claim in the README is also the strongest limitation. A tool that works with no network and no backend cannot ping a host, resolve a live DNS record, trace a route or capture a packet. Those operations need a socket and often elevated privileges, and a browser-based SvelteKit app has neither. So if your actual need is "find out why this host is unreachable," this is the wrong tool and no deployment option changes that. The same constraint applies to anything requiring current data, such as checking whether a domain is registered today or whether a certificate is still valid. The README's own framing supports this reading: the tools are for converting, calculating and verifying, and the tagline is offline-capable rather than monitoring or scanning. Read the tool list against your own workflow before deploying, because the gap between a subnet calculator and a network scanner is large and the marketing phrase "networking toolbox" does not draw that line for you.

Where a single-purpose calculator or a shell one-liner wins instead

The obvious alternative for many of these tasks is the command line you already have. ipcalc, sipcalc, dig and openssl cover subnet math, DNS lookups and certificate inspection without a container, a build step or a browser tab. The difference in approach is not quality, it is state. A shell command runs against live data and returns current results; Networking Toolbox runs a self-contained calculation with no network access and no dependency on the target being reachable. That makes the toolbox better when you are working from a specification, a ticket or a config file and the target is not something you can query, and worse when the answer depends on the network actually responding. A second alternative is the ad-supported web calculator, which is the thing this project is reacting to. The trade is straightforward: you give up convenience and someone else's hosting in exchange for not pasting internal addresses into a third-party form. If that exchange does not matter to you, the shell tools are lighter.

Licence and the practical cost of self-hosting

The repository is MIT licensed, with the README pointing at a gist copy of the licence text and crediting Alicia Sykes with a 2026 copyright line. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a summary of what the licence family generally permits, not legal advice, and if you plan to redistribute a modified build inside a product you should read the actual text rather than this paragraph. Operationally, the cost is small but not zero. You own the container or static bundle, the Node version, and the redeploy when a new tag appears. There is no hosted tier described in the material, so there is no vendor to fall back on if a build breaks. The upside is the same property: no external service in the request path, which is the whole point of the offline-first design.

Editorial conclusion

Adopt Networking Toolbox if you want a private, offline-capable reference for subnet math, conversions and config verification, and you are comfortable running Node or Docker. Skip it if you need live scanning, packet capture or anything that touches a real interface, because the README describes an offline-capable client-side toolset rather than a probing suite. Before committing, run yarn test and yarn build-check on your target Node version, and confirm the DEPLOY_ENV value that matches your host.

Official sources

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