# ktor-documentation: the source of the Ktor docs at ktor.io > The ktor-documentation repository holds the Markdown and XML that becomes the Ktor documentation site, built with JetBrains Writerside, with runnable code samples kept as a separate Gradle project so the snippets in the docs are compiled rather than copied. It suits a developer who wants to see how a framework documents itself or who wants to fix something in it, and the detail to understand first is that the table of contents is a file in the repository rather than a set of folders. **ktorio/ktor-documentation** — Documentation for the Ktor framework. - Repository: https://github.com/ktorio/ktor-documentation - Website: https://ktor.io/docs/welcome.html - Stars: 542 · Forks: 374 - Language: Kotlin - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ktorio-ktor-documentation ## What the repository actually contains This repository contains the documentation of the Ktor framework, published on ktor.io/docs, and it carries the badge that marks it as an official JetBrains project. The split worth understanding first is that this is not the framework. The Ktor framework itself lives elsewhere, in the ktorio organisation as a separate repository. What is here is the prose, the images and the runnable samples that make up the documentation site. That matters for two reasons. A developer looking for how to use Ktor wants the published site, not this repository. And a developer who wants to contribute a documentation fix comes here, where the contribution path is explicitly described with a link to the contribution guidelines and a YouTrack issue filter for documentation bugs. The documentation is published at https://ktor.io/docs/welcome.html, and the project is written in Kotlin with the topic tags documentation, kotlin, ktor, ktor-client, ktor-framework and ktor-server, which reflect that the docs cover both the server side and the client side of the framework. The licence is Apache 2.0, the default branch is main, and the last push was on 2026-10-15. There are no GitHub releases, which is what you would expect from a repository whose output is a website rather than a distributable artefact. The repository also carries a `CODE_OF_CONDUCT.md`, a `renovate.json` for dependency updates, and a `.gradle/` directory, which tells you that a Gradle project lives inside the repository even though the documentation itself is not a Gradle project. ## Writerside, and the seven things in the project structure The project is built with Writerside, the JetBrains documentation authoring tool, and the README describes the resulting project structure precisely. It is worth reading because the names are not self-explanatory. `/cfg` contains configuration files. `/codeSnippets` contains a Gradle project with runnable code samples demonstrating Ktor capabilities, and there is a separate Code Snippets Doc explaining how to run the samples and reference them in topics. `/images` contains images and GIFs used in topics. `/templates` has a single `settings.zip` file containing IntelliJ IDE settings. `/topics` contains documentation files in Markdown and XML. Then three files at the root with names that do not describe what they do. `ktor.tree` defines the table of contents. `c.list` contains a list of categories that define groups of related links for the See also section of a topic. And `v.list` contains a list of global project variables. The table of contents being a file rather than a directory structure is the most interesting of the three. It means the navigation of the documentation site is an explicit artefact that can be reviewed as a diff, which is a considerable advantage over inferring the structure from the filesystem. When a page moves, the change shows up as a change in one readable file rather than as a rename that a directory-based approach would treat as a delete and an add. The `c.list` file is a documentation pattern worth borrowing. The See also section of a topic is a set of related links, and the categories file defines the groups those links fall into. Making the grouping a shared definition rather than something each page repeats is how a documentation set stays consistent as it grows, and it is why a link in one topic points at a category rather than at a hand-picked list. The global variables file has the same motivation. Values that appear in many pages, the version number, the artifact coordinates, a date, are defined once and referenced, so a change to them does not require touching every topic that mentions them. The IntelliJ settings in `templates/` are there so that a contributor's editor behaves the way the documentation expects. The README does not say what those settings are, but the existence of a `settings.zip` is the usual way to ship a formatting convention alongside a documentation project. ## Code samples that are compiled rather than pasted The `codeSnippets` directory is the part of this repository with the most engineering behind it, and the reason is straightforward. The samples are a Gradle project with runnable code samples demonstrating Ktor capabilities. There is a documentation file describing how to run the samples and how to reference them in topics, which tells you the samples are not free-floating snippets but are built and referenced from the pages that show them. That is the point. A code sample in documentation is a liability unless somebody runs it. The sample compiles against the current version of the framework, so a change to an API breaks the build rather than silently making the documentation wrong. And a reader who wants to try a sample can run it rather than transcribing it. The reference mechanism is the part that matters for the writer. A topic does not paste the code; it points at a sample in the Gradle project, and the build tooling includes it. So the code you read on the site is the code that was compiled, which is a stronger guarantee than a snippet someone pasted and forgot. The project structure also has a `diagrams/` directory that is not mentioned in the README's list, alongside the `images/` directory that is. Diagrams and images are different things in a documentation tool: an image is a picture, and a diagram is a drawing built from a description, which can be regenerated and kept consistent with the surrounding text. A separate directory for them suggests the diagrams are maintained as sources rather than as exported files. The Gradle nature of the samples also means the samples project is the slowest part of a documentation change to build, since it pulls in the framework. That is the cost of the guarantee, and it is a cost that is worth paying for samples that show a framework's API. ## Versioning, redirects and the site plumbing Several files at the repository root exist to manage the published site rather than the content, and they are worth naming because they are easy to miss. `help-versions.json` is the clearest. Its name suggests it lists the versions of the documentation that are published, which is how a framework site keeps the docs for the current release and the previous one side by side. A Ktor user on an older release needs the docs that match their version, and that is a publishing configuration rather than a content problem, so it belongs in the repository rather than in a deployment script. `redirection-rules.xml` does the same job for URLs that have moved. When a topic is renamed or reorganised, the old URL has to keep working, because documentation URLs end up in forum posts, in issue trackers and in other people's blog posts, and a broken link there is a permanent annoyance. Keeping the redirect table in the repository means the redirects are reviewed like any other change. `labels.list` sits alongside `c.list` and `v.list`, and by the naming pattern it is the analogous mechanism for labels, the tags used to mark a topic for a particular audience or state. `project.ihp` is the Writerside project file, the one file that ties the configuration, the tree, the topics and the lists together into a project that the tool can build. The `.github/` directory holds the images used by the feedback prompt screenshot in the README, both the light and the dark variants, which is a small detail that says the repository follows the same light and dark media handling the documentation site does. There is also a `preview.jpg` at the root and a `.DS_Store`, which is the macOS directory metadata file. Its presence in a committed repository is a small untidiness, and it is the kind of thing that belongs in `.gitignore`. The `.gitignore` is present, and the `renovate.json` shows that dependency updates are automated, which for a Gradle project means the samples' dependency versions get refreshed on a schedule rather than by hand. ## How feedback and support are handled The contribution and feedback sections say more about how the project is run than the structure does, and there are two distinct paths that are worth telling apart. For contributing a fix, the README points at the Contribution Guidelines in a CONTRIBUTING.md file, and for those who do not know where to start it points at the open issues on YouTrack, filtered to the Docs subsystem, state Submitted and type Bug. So a documentation bug has a home in the issue tracker that is separate from the repository, and it is filtered so that the documentation queue is visible as a list. For reporting a bug or proposing a feature, the invitation is to create a new issue on YouTrack with the same Subsystem filter, or to contribute to the repository. So the issue tracker is where reports go and the repository is where fixes go, and the two are not separate destinations for the same thing. The feedback loop is the third path and it is the most interesting, because it closes the loop on published content rather than on the source. At the bottom of each documentation page published on ktor.io/docs there is a Was this page helpful? prompt. Selecting Yes sends positive feedback automatically, and selecting No opens a feedback form to fill out, with the instruction to give as much detail as possible. The Ktor team consistently reviews and addresses received feedback. That is a well-designed arrangement for a documentation set, because the page-level prompt catches the one thing a bug tracker cannot: the page that is technically correct but that nobody understood. Someone who followed it and got stuck reports it without having to work out where to file it, and the review commitment means the report is acted on. Support questions themselves are directed elsewhere. For any Ktor-related support questions, the project asks for Stack Overflow with the ktor tag, and for peer-to-peer support, the Ktor channel on Slack. So the documentation repository handles documentation, the issue tracker handles documentation bugs, and general usage questions belong on Stack Overflow. The README closes with a thank-you to the community, with the note that the team appreciates support and efforts towards improving Ktor and Ktor Documentation. ## Conclusion Adopt this repository as your starting point if you are looking for a worked example of how a Kotlin framework documents itself, since the structure shows how topic pages, snippets and navigation are separated. Do not expect to find the Ktor framework source here, because this holds only the documentation, and check first that the behaviour you are asking about is in the current version, since the repository carries a help-versions.json and a redirection-rules.xml for the versioned parts of the site. ## FAQ ### What is the ktor-documentation repository? It is the repository containing the documentation of the Ktor framework, published on ktor.io/docs, and it is an official JetBrains project. It holds the Markdown and XML topics, the images, the runnable code samples and the navigation configuration for the documentation site, and it is licensed under Apache-2.0. ### How is the Ktor documentation built? With Writerside, the JetBrains documentation authoring tool. The topics live in the topics directory in Markdown and XML, the table of contents is defined in ktor.tree, the See also categories in c.list, the global project variables in v.list, the configuration in the cfg directory, and the IDE settings in a settings.zip under templates. ### How are the code samples in the Ktor docs kept correct? The codeSnippets directory is a Gradle project with runnable samples, and there is a Code Snippets Doc explaining how to run them and how to reference them in topics. Because the samples are compiled as part of the project, a change to a Ktor API breaks the build rather than making the documentation quietly wrong. ### How do I report a documentation bug in the Ktor docs? Create a new issue on YouTrack with the Docs subsystem, or contribute a fix to the repository following the Contribution Guidelines. If you do not know where to start, the README points at the open issues on YouTrack filtered to the Docs subsystem, state Submitted and type Bug. ### What is the page feedback prompt on ktor.io? At the bottom of each published documentation page there is a Was this page helpful? prompt. Selecting Yes sends positive feedback automatically, while No opens a feedback form to fill out with as much detail as possible, and the Ktor team reviews and addresses the feedback received. ### Is ktor-documentation still being maintained? The repository is not archived and the last push was on 2026-10-15, with no GitHub releases. The site keeps versioned documentation through a help-versions.json file and handles moved pages with redirection-rules.xml, and dependency updates are handled by renovate.json. ## Sources - [Issues](https://github.com/ktorio/ktor-documentation/issues) - [ktorio/ktor-documentation on GitHub](https://github.com/ktorio/ktor-documentation) - [License: Apache-2.0](https://github.com/ktorio/ktor-documentation/blob/main/LICENSE) - [Project website](https://ktor.io/docs/welcome.html) - [README](https://github.com/ktorio/ktor-documentation/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ktorio-ktor-documentation