engineering
You Don't Own Your Docs
You have the Markdown. Can you rebuild the site, take the design and search with you, and keep the links people already use?
You wrote your documentation. You maintain it in pull requests. The next question is whether you can still publish it if you leave your docs provider.
One way to test that is to build the site from your repo and serve the output somewhere else. If that takes a migration project, the source files were portable but the published site was not.
The part you own and the part you don’t
You have your Markdown in the repo and an OpenAPI spec you can read. Stop Renting Your OpenAPI Docs makes the case that the spec was portable the whole time; the same is true of Doxygen comments and Go doc comments. The inputs were designed to be moved.
The published site includes more than the source: build rules, URLs, search, navigation, and styling. Check which of those you can reproduce from the repo. A working export of Markdown alone does not answer that question.
This is a practical question about being able to publish. Using a hosted service does not, by itself, mean you have given away the copyright to your writing.
The dependencies accumulate
Every page, cross-reference, and bookmarked deep link adds work to a move. A docs site with fifty pages is easier to relocate than one with five hundred, especially if URLs change.
Before a docs site gets large, try a second build path. It is much easier to find the hidden dependencies while there are only a few pages to inspect.
A custom component can hide one. So can an image uploaded through the web editor, a search index built only by the provider, or a navigation setting that was never committed. The repo can look complete until you try to publish it from a clean checkout.
When the setup changes
Prices and product boundaries change. If a hosted feature becomes too expensive or a project needs different publishing rules, the team needs to know what it can take with it. A repeatable build and a URL plan make that answer concrete.
Hosted editing, review workflows, and support can be worth paying for. If they let people contribute who would otherwise never touch the docs, include that in the decision. Compare the service bill with the work your team would take on, including upgrades, previews, access controls, and failed builds.
Keep the part people came to read
Portability should include the presentation. Exporting the words and leaving behind the site everyone liked is a fairly miserable exit.
The MailSchema specification shows what we want from Sourcey. It is a technical document with a strong identity: generous type, clear chapter navigation, a visible draft status, and a layout you can spend time in. Its specification pages use Sourcey’s reader theme through the Astro integration, with project fonts, colour, and CSS configured in the repository.
That distinction matters. The theme supplies the reading layout; the project can make it feel like its own. The result is something worth keeping when the hosting changes.
The reader has already saved the URL
The buyer may be choosing between screenshots, but the reader is trying to solve a specific problem: find an argument, check a schema, or follow a setup step. We also need the pages to be legible to tools that retrieve them. That is why we care about stable URLs and readable generated output.
Documentation Is the Contract Surface looks at what happens when a human or agent relies on those pages to use an API.
Ownership is an economic argument
The practical goal is a build you can run and inspect. Static HTML can be hosted in several places, and you can diff it between releases. Moving a published site still takes work: redirects, search checks, analytics, and a pass over links. Having the output in hand makes that work manageable.
Sourcey produces a static site from your project’s sources. The built pages, styling, and local search can move together. You can inspect the output, keep it with a release, and host it without a running Sourcey service. A hosting decision does not have to become a decision to redesign the docs.
The same should apply to the copy an agent reads. Sourcey 3.7.1 writes page, operation and schema Markdown into the build directory, with an index that links each document back to its browser reference. You can distribute the files with a release, use them in a retrieval pipeline or serve the directory through the optional docs MCP package. Readable exports and discovery are configured with the project; static hosting continues to serve ordinary files.
Discovery needs its own place in an exit drill. If your docs live under /docs, the surrounding website still owns the domain’s root manifest. Keep the scoped manifest and its links with the documentation, and update the host’s reference when moving it. Check the media types too: an API catalog at an extensionless URL still needs to be served as a Linkset. A copied file and a correctly published resource are separate checks.
Move the finished site, including its search
For a concrete check, we built the Cheesestore documentation from a clean source archive and copied the generated files unchanged to a second local host. Both hosts served the extensionless HTML routes the site uses.
All ten HTML pages opened on each host. The collected internal links and anchors resolved. Searching for pagination returned the expected results on both copies. The browser recorded no requests to external origins during those checks.
The layout, reference, and search travelled with the output. There was no Sourcey process running beside either site to keep them working.
The check used revision 24183838b8ed7ab8e2ce10f8d37a44936adf8986, its committed lockfile, and Sourcey 3.6.12. It moved the demo between local hosts; a public domain move also needs the URL and redirect work below.
Keep the build inputs with the build
Serving yesterday’s site and building tomorrow’s edition require different things. Keep the generated output so you can serve it. Keep the sources and build configuration so you can change it.
Nitrosend’s docs bring authored guides, a local MCP definition, and an OpenAPI source from its API into one site. For that kind of setup, the inputs include more than the Markdown folder. A reproducible edition needs the relevant interface definitions and the tool versions that rendered them.
Keep the design inputs too. MailSchema’s fonts, navigation, and branding are part of the site people recognise. Treat them as project files, with the same care as the writing, so a rebuild does not depend on recovering settings from somebody’s account.
When changing the public host, update the site URL and preserve the routes you intend to keep. A base path such as /docs/, canonical URLs, and old deep links belong in the migration plan. Readers may arrive through an issue or bookmark written years before the move.
A fragment needs special attention. In /api#operation/createOrder, the browser does not send #operation/createOrder to the server. A server-side redirect can move /api; it cannot choose a different destination by inspecting a fragment it never received.1 Preserve old IDs where possible, or provide an explicit client-side anchor mapping. Test the complete bookmarked URL, not just the page before the #.
The next edit matters too
Ownership is also practical. Can another authorised person correct a paragraph, preview it, and publish the result? Do they know where navigation, images, fonts, and generated inputs live? Can they identify which release reached the site?
Keep the editing and publishing instructions beside the sources. A teammate should be able to make the next correction without asking the person who originally set up the site. If your team needs a hosted editor and review workflow, account for that requirement when choosing the tooling; possessing the output does not supply the workflow.
Run a small exit drill
Start with the files needed for the build: source, config, lockfile, images, fonts, and any generated reference inputs. Write down the tools that produce those inputs, such as Doxygen or Go. Keep credentials out of the published output.
Build from a clean checkout and copy only the finished site to another static host. Open a deep link directly, refresh it, search for a symbol, follow a schema link, and read a long page on a phone. Watch the network requests. An externally hosted image or search service can still be a dependency even though the HTML is local.
Then check the URL plan. A domain you control lets you move hosts while retaining the address, but paths, fragments, redirects, and canonical URLs still need attention. Keep the previous build artifact so you can restore it if the move fails.
Record what worked and what needed fixing. That gives you an actual cost for leaving, before you need to leave. The economics of paying for documentation look different once you include that cost.