On-Prem & Air-Gapped API Docs
Docs for on-prem, regulated & air-gapped teams
The constraint isn't a preference, it's a rule
How DSR Docs meets it
What it actually does once it's inside
When it's the right fit — and when it isn't
Docs for on-prem, regulated & air-gapped teams If your compliance, security, or classification rules say the documentation can't live in a cloud SaaS, DSR Docs is built for exactly that constraint you self-host your API and product docs entirely inside your own environment, running as one container that never phones home, so nothing leaves the network you control. Most modern doc platforms are cloud-only, which is precisely the gap this closes. The constraint isn't a preference, it's a rule If you're on a defense, fintech, healthcare, or embedded team, "just use the hosted docs product" often isn't on the table. The blocker is rarely the docs themselves — it's where they run. Data residency policy, a classified or air-gapped network, a procurement process that won't approve another vendor holding your content, or an auditor who wants the evidence trail on infrastructure you can point to. A cloud-only platform fails all four before you even evaluate its features. So the real question isn't "which doc tool has the nicest editor" — it's "which one can run where my rules say it has to." How DSR Docs meets it DSR Docs is software you deploy, not a service you send your content to. It ships as one container that runs entirely inside your environment — a VM, a box in your rack, or an isolated network with no internet reachback — so every page, spec, and reader request stays where you put it. There's no external tier holding your accounts, content, or search index; sign-in, roles, versioning, and full-text search all run inside the container you operate. Because it can be transferred into an air-gapped environment and started with no outbound calls required, "no internet" is a supported deployment, not a failure mode. What it actually does once it's inside This isn't a stripped-down offline build — it renders the same references a hosted tool would. OpenAPI 3.x for REST, GraphQL from SDL or introspection, and Doxygen for C/C++ and embedded SDKs (including call and caller graphs), all natively, alongside long-form Markdown guides with diagrams, code highlighting, and callouts. One schema kind attaches per domain, so a mixed REST-plus-C++ estate is split across domains or tabs rather than crammed into one. Non-engineers edit in an in-app browser editor. Branding — name, logo, favicon, colors, fonts — is white-label and hot-applied with no rebuild. And for the AI and offline workflows regulated teams still need, there's a "Copy for LLM" button, an , a Markdown alternate for each page, and one-click print-to-PDF — outputs you generate from your own instance, not a cloud service. For OpenAPI operations it ships a built-in "try it" console that fires live requests against a server URL you configure — with path, query, header, and body editors, API-key/bearer/OAuth auth, and response status, body, and latency — so interactive testing of your REST reference works out of the box. One honest limit worth stating up front it does not generate client SDKs. If your docs strategy depends on auto-generated SDK downloads, that's a gap you should weigh now, not later. Two things regulated teams usually have to give up, and here do not. Diagrams the draw.io editor is vendored into the container and served from your own origin, with cloud-storage connectors stripped and a Content-Security-Policy whose is — a test drives the real editor through a real diagram and fails on a single off-origin request, so drawing works with the network unplugged. Readership figures analytics is built in rather than pasted in from a third-party tracker, so you can see which pages are read without any reader data leaving the perimeter — no IP address is stored in any row, and the country lookup uses a local table rather than an external service. When it's the right fit — and when it isn't Reach for DSR Docs when self-hosting is a hard requirement regulated industry, on-prem or air-gapped operation, a residency policy, or a procurement rule against another SaaS holding your content. Cost helps here too you buy a license and run it on your own infrastructure, and the license isn't priced per seat, per viewer, or per published site, so adding editors or readers doesn't inflate the bill — see Documentation without per-seat pricing. It's the wrong fit if none of those constraints apply. If you're happy for a vendor to run hosting, scaling, and upgrades and nothing forces the docs onto your own infrastructure, a fully managed product removes operational work that DSR Docs asks you to own — the trade-off we lay out in DSR Docs vs Mintlify. The point of running it yourself is control; if you don't need the control, you're taking on the operations without collecting the reason for them. [!IMPORTANT] Sounds like your case? Write to docs@dsr-corporation.com. We'll show you the engine on documentation like yours, and say plainly what a move would involve.