<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blog on Valoryx</title>
    <link>https://valoryx.org/blog/</link>
    <description>Recent content in Blog on Valoryx</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 13 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://valoryx.org/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The Future of Docs Is AI-Native</title>
      <link>https://valoryx.org/blog/ai-native-documentation/</link>
      <pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/ai-native-documentation/</guid>
      <description>Documentation has a maintenance problem. You write a guide, publish it, and within three months it&amp;rsquo;s outdated. The API changed. The config format was refactored. A dependency was replaced. The screenshots show a UI that no longer exists.&#xA;The solution isn&amp;rsquo;t &amp;ldquo;write better docs&amp;rdquo; or &amp;ldquo;build a docs culture.&amp;rdquo; Teams have been trying that for decades. The solution is to make documentation aware of the code it describes — so when the code changes, the docs know about it.</description>
    </item>
    <item>
      <title>The Real Cost of Documentation Platforms</title>
      <link>https://valoryx.org/blog/documentation-platform-cost/</link>
      <pubDate>Thu, 09 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/documentation-platform-cost/</guid>
      <description>Per-seat pricing seems reasonable at first glance. Five users at $8/month? That&amp;rsquo;s $40. Your team can afford $40.&#xA;But documentation is one of those tools where the number of people who should have access keeps growing. Engineers need to write. Product managers need to review. Support staff need to reference. New hires need to read and annotate. Suddenly you&amp;rsquo;re not at 5 seats — you&amp;rsquo;re at 50, and that &amp;ldquo;affordable&amp;rdquo; $8/seat is $400/month for a tool that stores text files.</description>
    </item>
    <item>
      <title>Documentation for Open Source Projects</title>
      <link>https://valoryx.org/blog/docs-for-open-source/</link>
      <pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/docs-for-open-source/</guid>
      <description>Open source projects live or die by their documentation. A library with great docs gets adopted. A library with a bare README and a &amp;ldquo;see the code&amp;rdquo; attitude gets forked by someone who writes better docs — or just ignored.&#xA;But most documentation tools are built for companies, not OSS maintainers. They charge per seat, per page, or per workspace. For a project maintained by volunteers with zero budget, that&amp;rsquo;s a non-starter.</description>
    </item>
    <item>
      <title>How Documentation Search Actually Works</title>
      <link>https://valoryx.org/blog/documentation-search-works/</link>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/documentation-search-works/</guid>
      <description>You type a query into your documentation search bar. Results appear. But what happened between the keystroke and the results? For most documentation platforms, the answer is either &amp;ldquo;not much&amp;rdquo; (basic keyword matching that misses obvious results) or &amp;ldquo;a lot of infrastructure&amp;rdquo; (an Elasticsearch cluster that your ops team has to maintain).&#xA;There&amp;rsquo;s a middle ground that most teams don&amp;rsquo;t know about: embedded full-text search. DocPlatform uses Bleve, a search library written in Go, compiled directly into the binary.</description>
    </item>
    <item>
      <title>Why We Ship a Single Go Binary</title>
      <link>https://valoryx.org/blog/single-binary-architecture/</link>
      <pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/single-binary-architecture/</guid>
      <description>Most documentation platforms ship as a stack. You get a Node.js application, a PostgreSQL database, a Redis cache, an Elasticsearch cluster for search, and an Nginx reverse proxy to tie it all together. Five services, five things that can break, five things to monitor, patch, and upgrade.&#xA;DocPlatform ships as one file. Download it, run it, done.&#xA;This isn&amp;rsquo;t a marketing trick. It&amp;rsquo;s an architecture decision we made on day one, and every design choice since then flows from it.</description>
    </item>
    <item>
      <title>How to Keep Documentation Up to Date</title>
      <link>https://valoryx.org/blog/keep-docs-up-to-date/</link>
      <pubDate>Thu, 26 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/keep-docs-up-to-date/</guid>
      <description>Every engineering team has the same documentation problem. Someone writes thorough docs during a launch. Six months later, the API has changed, the configuration format is different, and three pages reference a feature that was renamed. Nobody updated the docs because updating docs is a separate task from writing code, and separate tasks get forgotten.&#xA;The usual advice — &amp;ldquo;make documentation part of your culture&amp;rdquo; — doesn&amp;rsquo;t work. Culture doesn&amp;rsquo;t survive deadline pressure.</description>
    </item>
    <item>
      <title>Self-Hosted Docs for Regulated Teams</title>
      <link>https://valoryx.org/blog/docs-regulated-industries/</link>
      <pubDate>Mon, 23 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/docs-regulated-industries/</guid>
      <description>If you work in healthcare, defense, finance, or any industry where data residency matters, you&amp;rsquo;ve already had the conversation: &amp;ldquo;Can we use this SaaS tool, or does it need to go through a six-month security review?&amp;rdquo; For most cloud documentation platforms, the answer is the review — and it often ends with &amp;ldquo;no.&amp;rdquo;&#xA;The issue isn&amp;rsquo;t that cloud tools are insecure. Most of them are competent at security. The issue is control.</description>
    </item>
    <item>
      <title>How Bidirectional Git Sync Works</title>
      <link>https://valoryx.org/blog/bidirectional-git-sync/</link>
      <pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/bidirectional-git-sync/</guid>
      <description>Every documentation platform with a git integration page makes the same promise: your docs live in git, your team edits in the browser, and everything stays in sync. In practice, most of these integrations are one-way mirrors that fall apart the moment two people edit from different directions.&#xA;We wrote about why this happens in a previous post. This one goes deeper into the solution: how Valoryx implements bidirectional sync using the Content Ledger pattern, and why this approach handles the scenarios that break other tools.</description>
    </item>
    <item>
      <title>MCP for Documentation: A Technical Guide</title>
      <link>https://valoryx.org/blog/mcp-documentation-guide/</link>
      <pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/mcp-documentation-guide/</guid>
      <description>Model Context Protocol (MCP) is an open standard that lets AI assistants interact with external tools and data sources through a structured interface. Instead of copying text into a chat window and hoping the model understands the context, MCP gives the assistant direct, typed access to your systems — read files, run searches, create content, all through well-defined tool calls.&#xA;For documentation teams, this changes the workflow fundamentally. Your AI assistant stops being a text generator that works from stale context and becomes a participant that reads your actual docs, searches across your knowledge base, and makes edits you can review before they go live.</description>
    </item>
    <item>
      <title>Internal Docs Developers Actually Read</title>
      <link>https://valoryx.org/blog/internal-docs-developers-use/</link>
      <pubDate>Thu, 12 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/internal-docs-developers-use/</guid>
      <description>Every engineering organization has internal documentation. And in most of them, that documentation is incomplete, outdated, or ignored. According to the 2024 Stack Overflow Developer Survey, a majority of developers consider poor or missing documentation a significant productivity barrier. This isn&amp;rsquo;t a discipline problem. It&amp;rsquo;s a tooling problem.&#xA;Internal docs fail for specific, fixable reasons. The tools make writing painful. The content rots because nobody has a workflow for keeping it current.</description>
    </item>
    <item>
      <title>Your Docs Should Be in Git. Period.</title>
      <link>https://valoryx.org/blog/docs-should-be-in-git/</link>
      <pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/docs-should-be-in-git/</guid>
      <description>Here&amp;rsquo;s an inventory of what a typical engineering team keeps in git:&#xA;Application source code Infrastructure definitions (Terraform, Pulumi, CloudFormation) CI/CD pipeline configurations Database migration scripts API specifications (OpenAPI, protobuf) Deployment manifests (Kubernetes, Docker Compose) Environment configuration templates And here&amp;rsquo;s what usually lives outside git:&#xA;Documentation This is strange. Documentation describes the system. It changes when the system changes. It needs review, versioning, attribution, and the ability to roll back. Every other artifact that shares these properties lives in git.</description>
    </item>
    <item>
      <title>Documentation as Code: A Practical Guide</title>
      <link>https://valoryx.org/blog/documentation-as-code/</link>
      <pubDate>Thu, 05 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/documentation-as-code/</guid>
      <description>&amp;ldquo;Documentation as code&amp;rdquo; gets thrown around a lot. At its simplest, it means treating documentation the same way you treat source code: stored in version control, written in plain text, reviewed through pull requests, and built through CI/CD. But there&amp;rsquo;s a gap between the idea and actually doing it well. This guide covers what docs-as-code is, what approaches exist, and where each one falls short.&#xA;Why Docs-as-Code Matters Software teams already have workflows for managing change.</description>
    </item>
    <item>
      <title>Self-Host Your Docs in 5 Minutes</title>
      <link>https://valoryx.org/blog/self-host-docs-5-minutes/</link>
      <pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/self-host-docs-5-minutes/</guid>
      <description>Most self-hosted documentation tools require a database, a reverse proxy, and half an afternoon of YAML editing before you see a welcome screen. DocPlatform is a single Go binary with zero external dependencies. This tutorial takes you from nothing to published documentation in about five minutes.&#xA;Prerequisites You need a Linux, macOS, or Windows machine. That&amp;rsquo;s it. No Docker, no PostgreSQL, no Node.js runtime. DocPlatform compiles to a single static binary — the Go runtime is embedded.</description>
    </item>
    <item>
      <title>Self-Hosted Notion Alternative for Dev Teams</title>
      <link>https://valoryx.org/blog/notion-alternative-self-hosted/</link>
      <pubDate>Sun, 01 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/notion-alternative-self-hosted/</guid>
      <description>Notion is everywhere. Design teams use it for briefs. Product teams use it for roadmaps. Marketing teams use it for content calendars. And increasingly, engineering teams use it for documentation — technical specs, runbooks, onboarding guides, API references.&#xA;It works, up to a point. Then you hit the edges, and the edges are sharp.&#xA;This post is for teams who&amp;rsquo;ve hit those edges and are looking for something better — specifically for technical documentation that belongs in a git repository, not a proprietary database.</description>
    </item>
    <item>
      <title>Self-Hosted Documentation Tools Guide (2026)</title>
      <link>https://valoryx.org/blog/self-hosted-docs-guide/</link>
      <pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/self-hosted-docs-guide/</guid>
      <description>Self-hosted documentation is having a moment. After years of SaaS platforms raising prices, changing terms, and shutting down without warning, more teams are choosing to run their own documentation infrastructure. The reasons are straightforward: data ownership, cost control, compliance, and the comfort of knowing your knowledge base won&amp;rsquo;t disappear when a startup runs out of funding.&#xA;But the self-hosted documentation landscape is crowded and confusing. There are wiki platforms, static site generators, knowledge bases, and hybrid tools — each with different trade-offs.</description>
    </item>
    <item>
      <title>GitBook vs Valoryx: Honest Comparison</title>
      <link>https://valoryx.org/blog/gitbook-vs-valoryx/</link>
      <pubDate>Wed, 25 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/gitbook-vs-valoryx/</guid>
      <description>GitBook is one of the most popular documentation platforms for developer teams. It has a polished editor, solid collaboration features, and good-looking published docs. If you&amp;rsquo;re evaluating documentation tools, it probably showed up on your list.&#xA;We built Valoryx to solve problems that GitBook doesn&amp;rsquo;t address — primarily around git ownership, self-hosting, and pricing transparency. But we want to give you an honest comparison, not a marketing page. Here&amp;rsquo;s where each tool shines and where each falls short.</description>
    </item>
    <item>
      <title>Why Git Docs Tools Break Sync</title>
      <link>https://valoryx.org/blog/why-git-sync-breaks/</link>
      <pubDate>Sun, 22 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://valoryx.org/blog/why-git-sync-breaks/</guid>
      <description>If you maintain technical documentation, you&amp;rsquo;ve probably been burned by this promise: &amp;ldquo;Full git integration.&amp;rdquo; You connect your repo, make some edits in the web UI, push a commit from your IDE — and everything falls apart. Merge conflicts. Lost edits. Pages that silently revert. A sync status that says &amp;ldquo;up to date&amp;rdquo; while your content diverges.&#xA;This isn&amp;rsquo;t a bug in any single product. It&amp;rsquo;s a fundamental design flaw in how most documentation platforms think about git.</description>
    </item>
  </channel>
</rss>
