Self-Hosting Networking Toolbox - Offline-First Network Utilities

Some tools are worth self-hosting because they are heavy systems of record.

Networking Toolbox is useful for the opposite reason: it is a fast workbench you can keep open while planning subnets, checking DNS records, building DHCP options, converting IP formats, or explaining networking details to someone else.

It feels like the network-engineering cousin of IT-Tools, but with a deeper focus on IP addressing, CIDR, DNS, DHCP, diagnostics, and reference material.

What is Networking Toolbox?

Networking Toolbox is an open-source networking utility app by Alicia Sykes.

• Networking Toolbox GitHub Source Code
• Networking Toolbox Hosted Demo
• Networking Toolbox Docker Image
• License: MIT ❤️

The project describes itself as:

The all-in-one offline-first networking toolbox for sysadmins

I inspected:

repo: https://github.com/lissy93/networking-toolbox
commit: 90d018f4efab6ddbe98bc37aae84f0d255515ebc
package version: 1.6.0
latest local git tag observed: v1.6.0
tested Docker image digest: docker.io/lissy93/networking-toolbox@sha256:c85cfbf1267e4d48ca6f5cfc4e019049c8a075ce0cd757fc01e22338e484e132
license: MIT

One small Docker detail matters: the source has a v1.6.0 tag, but docker manifest inspect lissy93/networking-toolbox:v1.6.0 did not find a matching Docker tag when I tested it. The latest image did exist, reported app version 1.6.0, and carried the inspected source revision. For the Home-Lab compose, I pinned the tested digest instead of using a moving latest tag.

What Tools Are Included?

Networking Toolbox is organized around practical network work:

• Subnetting: IPv4 subnet calculator, IPv6 subnet calculator, VLSM, supernetting, subnet planning.
• CIDR: mask conversion, splitting, summarizing, deaggregating, comparing, diffing, overlapping, and finding free space.
• IP tools: validation, normalization, representation conversion, IPv4/IPv6 mapping, ULA generation, EUI-64, random IPs, regex generation.
• DNS tools: record validators, reverse DNS, PTR generators, zone helpers, TTL tools, DNSSEC helpers.
• DHCP tools: option generators, PXE profiles, vendor option helpers, and configuration snippets.
• Diagnostics: DNS, HTTP, TLS, RDAP, BGP, AXFR, DNSBL, CT logs, mail TLS, ASN/geolocation, and related lookups.
• Reference pages: private/public IP ranges, common ports, ICMP, ARP/NDP, multicast, CGNAT, IPv6 address types, MTU/MSS, reverse zones, and more.

This is not a database-backed monitoring system.

It is a network calculator, reference, and diagnostics UI.

Tech Overview

The current source is a modern SvelteKit app:

The app has two important personalities.

First, it is a browser UI with calculators, reference pages, local preferences, bookmarks, themes, and offline behavior.

Second, it exposes a JSON API for many calculations. At the inspected commit, the API registry contained 75 calculation endpoints across subnetting, cidr, ip-address-convertor, and dns.

For example:

curl -fsS -X POST http://localhost:6162/api/subnetting/ipv4-subnet-calculator \
  -H 'content-type: application/json' \
  --data '{"cidr":"192.168.10.0/24"}'

That makes it useful as both a human-facing toolbox and a small local API for repeatable network calculations.

Self-Hosting Networking Toolbox with Docker

The upstream docs show:

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

For the Home-Lab version, I used host port 6162 and pinned the tested digest:

• Home-Lab Networking Toolbox Docker Compose

Start it:

docker compose up -d

Then open:

http://localhost:6162

The container listens on port 3000; the compose maps ${NETWORKING_TOOLBOX_PORT:-6162}:3000.

Stop it:

docker compose down

Configuration Notes

Networking Toolbox can be customized with NTB_ environment variables.

For a homelab or internal ops instance, the useful ones are:

The Home-Lab .env.sample disables analytics and keeps custom DNS resolver input restricted by default.

That matters because diagnostic tools are different from pure calculators. A subnet calculator is deterministic and local. A DNS or TLS diagnostic tool may cause the server to query something on behalf of a user.

Field Test

I smoke-tested the container locally.

Commands:

docker compose up -d
curl -fsS http://127.0.0.1:6162/health
curl -fsS http://127.0.0.1:6162/version
curl -fsSI http://127.0.0.1:6162/
curl -fsS http://127.0.0.1:6162/api
curl -fsS -X POST http://127.0.0.1:6162/api/subnetting/ipv4-subnet-calculator \
  -H 'content-type: application/json' \
  --data '{"cidr":"192.168.10.0/24"}'
curl -fsS -X POST http://127.0.0.1:6162/api/cidr/split \
  -H 'content-type: application/json' \
  --data '{"cidr":"10.0.0.0/24","count":4}'
docker compose down

Observed results:

• /health returned {"status":"healthy"};
• /version returned 1.6.0;
• the homepage returned HTTP 200;
• /api listed categories and endpoints;
• the IPv4 subnet calculator returned network, broadcast, mask, first host, last host, and host counts;
• the CIDR split endpoint split 10.0.0.0/24 into four /26 networks.

That confirms the Docker image serves the UI and the JSON calculation API correctly.

Safe Exposure Notes

Networking Toolbox is safer to expose than an open website scanner, but it is still not just a static HTML page when deployed with the Node/Docker server.

Some tools are pure client-side calculators. Others use server routes or external lookups.

For a private LAN, the default compose is straightforward.

For a public instance:

• put it behind authentication if it is meant for internal use;
• keep NTB_ALLOW_CUSTOM_DNS=false unless you explicitly need custom resolvers;
• keep NTB_BLOCK_PRIVATE_DNS_IPS=true;
• disable analytics if you want a private internal toolbox;
• use reverse-proxy rate limiting if untrusted users can access diagnostic endpoints.

How It Compares

Compared with Web-Check, Networking Toolbox is less about inspecting one public website and more about day-to-day network calculations and reference work.

Compared with LinkChecker, it is not a crawler.

Compared with IT-Tools, it overlaps in spirit, but the emphasis is networking: CIDR math, DNS, DHCP, subnet planning, IP formats, and protocol reference material.

I would keep it near a homelab dashboard, an internal wiki, or a network operations jump box.

Conclusion

Networking Toolbox is a good small self-hosted utility for anyone who regularly touches IP plans, DNS records, DHCP options, firewall rules, route summaries, or network troubleshooting notes.

It does not need a database, Redis, Postgres, object storage, or API keys.

It is a single Dockerized SvelteKit app with a useful UI, PWA behavior, and a JSON API for calculations.

FAQ

Is Networking Toolbox self-hostable?

Yes.

The simplest path is Docker:

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

The Home-Lab compose uses:

http://localhost:6162

Does it need a database?

No.

There is no Postgres, MySQL, Redis, SQLite, or object storage requirement. Settings and bookmarks are mostly browser/local configuration, while server-side routes provide API and diagnostic behavior.

Is it a static site or a server app?

It can be either, depending on how you build it.

The repo supports SvelteKit adapters for Docker/Node, static builds, Vercel, Netlify, and auto-detection. The Docker path runs a Node server on port 3000. The static path can be deployed to static hosting, but server/API-backed diagnostic behavior is not equivalent to the Docker/Node deployment.

For Cloudflare Pages specifically, use the static build path and treat it as a mostly frontend/PWA deployment. If you want the local JSON API and server-side diagnostic routes exactly as tested here, use the Docker/Node deployment instead.

Is it a PWA? Does it work offline?

Yes, it ships a web manifest and service worker.

Static assets and essential pages can be cached for offline use. Pure calculator-style tools are the best fit for offline use. API requests and diagnostics that require network access return an offline error when the network is unavailable.

Does it call third-party services?

The core calculators do not need external services.

Some diagnostic tools can perform network lookups or call external APIs. For example, the MAC lookup route uses api.maclookup.app, and diagnostics can query DNS, TLS, RDAP, BGP, CT logs, DNSBL, and similar public infrastructure.

Can it help with email DNS records?

Yes, but treat it as a DNS helper rather than a full email deliverability scanner.

Networking Toolbox has useful validators for email-adjacent DNS work:

• validate-mx-record for MX host and priority syntax;
• validate-txt-record for TXT values, including SPF- and DMARC-looking strings;
• validate-domain and validate-email for basic domain and mailbox syntax;
• reverse DNS / PTR helpers;
• DNSSEC helper tools;
• TTL helpers;
• diagnostic routes for mail/TLS-style checks.

That is useful when building or sanity-checking records for a homelab mail server, Google Workspace, Proton Mail, Microsoft 365, or transactional email provider.

It is not a replacement for Mail-Tester, Hardenize, MXToolbox, Google Postmaster Tools, or a full deliverability audit. It does not prove inbox placement, DKIM selector coverage, SMTP banner behavior, IP reputation, ARC alignment, BIMI readiness, MTA-STS hosting, or TLS-RPT reporting on its own.

What did an email DNS example show?

I tested a mailbox at j***@getleadarchitect.com as a practical example, keeping the local part masked here because this post is public.

The Networking Toolbox API syntax checks returned:

curl -fsS -X POST http://127.0.0.1:6162/api/dns/validate-email \
  -H 'content-type: application/json' \
  --data '{"email":"j***@getleadarchitect.com"}'

curl -fsS -X POST http://127.0.0.1:6162/api/dns/validate-domain \
  -H 'content-type: application/json' \
  --data '{"domain":"getleadarchitect.com"}'

The address and domain were considered syntactically valid. One caveat: in this version, the validate-email response normalized the test address oddly by dropping the @, so I would use it only as a basic syntax check.

Live DNS lookup for getleadarchitect.com showed:

MX: 1 smtp.google.com.
SPF: v=spf1 include:_spf.google.com ~all
DMARC: v=DMARC1; p=quarantine; rua=mailto:...; pct=100; adkim=s; aspf=s
MTA-STS TXT: not found
TLS-RPT TXT: not found

Then I used the local API validators against those values:

curl -fsS -X POST http://127.0.0.1:6162/api/dns/validate-mx-record \
  -H 'content-type: application/json' \
  --data '{"value":"smtp.google.com","priority":1}'

curl -fsS -X POST http://127.0.0.1:6162/api/dns/validate-txt-record \
  -H 'content-type: application/json' \
  --data '{"value":"v=spf1 include:_spf.google.com ~all"}'

The MX value passed with a warning that the hostname should ideally be fully qualified with a trailing dot. The SPF-style TXT value passed, with the expected warning that SPF policy should be validated carefully. The DMARC-style TXT value also passed as a TXT record and was detected as DMARC-like content.

My read: this domain has the core Google mail routing pieces in place, SPF is present, and DMARC is more serious than monitoring-only because it uses p=quarantine plus strict adkim=s and aspf=s alignment. The missing MTA-STS and TLS-RPT TXT records are optional, but they are worth considering if the goal is stronger mail transport policy and reporting.

What do MX, SPF, DKIM, DMARC, MTA-STS, and TLS-RPT mean?

Email DNS is several controls layered together:

So, if MTA-STS and TLS-RPT are not found, it does not mean email is broken. Mail can still be delivered, SPF can still work, DKIM can still sign mail, and DMARC can still enforce policy.

What it implies is narrower: the domain is not publishing the newer SMTP transport policy/reporting layer. For a small domain, that may be acceptable. For a business domain, I would consider adding MTA-STS and TLS-RPT after confirming the MX hosts, certificates, and mail provider guidance, because a bad MTA-STS policy can break mail delivery more dramatically than a missing one.

Does it have an API?

Yes.

Start with:

curl -fsS http://127.0.0.1:6162/api

Then call individual calculation endpoints with POST, for example:

curl -fsS -X POST http://127.0.0.1:6162/api/cidr/split \
  -H 'content-type: application/json' \
  --data '{"cidr":"10.0.0.0/24","count":4}'

Which tools are most useful for a homelab?

For a homelab, I would start with the tools that help you plan or audit internal network state without touching external targets:

• IPv4/IPv6 subnet calculators for VLANs, lab networks, VPN ranges, and container networks.
• VLSM and subnet planner for splitting a larger private range into app, infra, IoT, guest, storage, and VPN segments.
• CIDR split, summarize, compare, diff, overlap, and contains for firewall rules, routing tables, Cloudflare/Tailscale allowlists, and reverse-proxy ACLs.
• Next available subnet for finding room in an address plan, though see the API caveat below.
• Range-to-CIDR and wildcard masks for translating ranges into firewall, router, or ACL formats.
• DNS record validators and reverse DNS/PTR generators for local DNS zones.
• DHCP option helpers for PXE, controller discovery, and network boot experiments.
• ULA generator and EUI-64 tools for IPv6 lab planning.
• Common ports and networking reference pages for quick operational lookups.

The diagnostic tools are also useful, but they are the ones I would expose more carefully because they can perform live lookups.

Which API endpoints did I try locally?

I tested several safe calculation-style API calls against the Home-Lab container.

The API index returned 75 endpoints across:

subnetting,cidr,ip-address-convertor,dns

These worked cleanly:

curl -fsS -X POST http://127.0.0.1:6162/api/subnetting/ipv4-subnet-calculator \
  -H 'content-type: application/json' \
  --data '{"cidr":"192.168.50.0/24"}'

That returned the expected /24 details, including 192.168.50.1 as first usable host and 192.168.50.254 as last usable host.

curl -fsS -X POST http://127.0.0.1:6162/api/cidr/summarize \
  -H 'content-type: application/json' \
  --data '{"input":"192.168.1.0/25\n192.168.1.128/25\n192.168.2.0/24","mode":"optimize"}'

That summarized the two /25 blocks into 192.168.1.0/24 and kept 192.168.2.0/24.

curl -fsS -X POST http://127.0.0.1:6162/api/dns/validate-a-record \
  -H 'content-type: application/json' \
  --data '{"name":"nas.home.arpa","value":"192.168.1.10","ttl":3600}'

That validated the A record successfully.

curl -fsS -X POST http://127.0.0.1:6162/api/ip-address-convertor/ula-generator \
  -H 'content-type: application/json' \
  --data '{"count":2,"prefix":"fd"}'

That generated two RFC 4193-style ULA /64 networks.

One rough edge: POST /api/cidr/next-available returned Do not know how to serialize a BigInt when I called it through the JSON API with a valid desiredPrefix payload. That looks like an API serialization issue rather than a Docker problem. Until that is fixed upstream, I would use that tool through the UI or stick to the other CIDR API endpoints for automation.

What could be better in the Home-Lab compose?

I made one improvement after testing the API: the compose now drops all Linux capabilities, runs with a read-only root filesystem, and mounts /tmp as tmpfs.

Those settings passed a local smoke test:

docker compose config
docker compose up -d
curl -fsS http://127.0.0.1:6162/health
curl -fsS -X POST http://127.0.0.1:6162/api/cidr/summarize \
  -H 'content-type: application/json' \
  --data '{"input":"192.168.1.0/25\n192.168.1.128/25","mode":"optimize"}'

The remaining improvement I would consider is reverse-proxy authentication if this is reachable outside a trusted LAN. The app is useful and lightweight, but diagnostic routes should still be treated as user-triggered network activity.

Can I use the hosted public API instead?

The project documents a public API, but the public instance has rate limits.

For repeatable scripts, CI jobs, or internal tooling, self-hosting is better. You control the version, limits, DNS safety settings, and availability.

Is this the same as Web-Check?

No.

Web-Check inspects a public website and reports what it exposes. Networking Toolbox helps you calculate, convert, validate, and troubleshoot network data.

They complement each other: use Web-Check for public site posture, and Networking Toolbox for network planning and sysadmin calculations.