Run it inside your own network

Every tool on this site runs from a single container on your own infrastructure. No account, no licence key, and nothing to phone home to — including us.

docker run --rm -p 8796:8796 \
  ghcr.io/mgbuilderos/opentools:latest

Then open localhost:8796. A docker-compose.yml is in the repository if you would rather persist the cache and lock the container down.

Why organisations run it this way

If your staff handle client documents, contracts, medical records or anything under GDPR, HIPAA or India's DPDP Act, uploading those files to a third-party website is usually not allowed. In practice people do it anyway, because they have a PDF to compress and a deadline. Running this inside your own network removes the choice rather than relying on a policy nobody reads.

We can't tell you whether this satisfies your obligations — that depends on your jurisdiction, your data and your auditor, and anyone who tells you otherwise about their own product is guessing. What we can do is make the technical claim checkable.

It runs with no network at all

The image needs nothing at runtime, and you can confirm that yourself rather than take our word for it:

docker run --rm -d --network none --name opentools \
  ghcr.io/mgbuilderos/opentools:latest
docker exec opentools \
  node -e "fetch('http://127.0.0.1:8796/').then(r=>console.log(r.status))"

That prints 200 with no network available to the container. Measured against this image: every page served, and an outbound request from inside it failed to resolve.

Separately, the pages themselves are served with connect-src 'none', which makes the browser refuse every network request the page could attempt. A test in the repository tries five ways to exfiltrate data on every release and asserts zero off-origin bytes during a real file operation, in both Chromium and WebKit.