# xrpl-dev-portal: the documentation repository behind xrpl.org

> One repository holding the XRP Ledger developer documentation, the marketing pages, the API examples and the translations, built and previewed with Redocly Realm, with a review board and a licensing inconsistency worth knowing about.

**XRPLF/xrpl-dev-portal** — Source code for xrpl.org including developer documentation

- Repository: https://github.com/XRPLF/xrpl-dev-portal
- Website: https://xrpl.org
- Stars: 2,228 · Forks: 1,182
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/xrplf-xrpl-dev-portal

## One repository for developer docs and the public website

The repository description states the scope plainly: source code for xrpl.org including developer documentation. The README expands on the claim, calling the XRP Ledger Dev Portal the authoritative source for XRP Ledger documentation, including the core server, client libraries and other open-source XRP Ledger software.

What makes the tree more interesting than a single docs folder is how many kinds of content sit side by side. There is a docs directory for reference material, about and community directories for the non-technical pages, a blog directory, a develop directory, and resources for supporting material. Then the pieces that make documentation for a protocol unusually hard: an _api-examples directory and a _code-samples directory, both prefixed with an underscore, which is the convention for holding something back from the top-level navigation.

Configuration files reveal how much of the site is data rather than prose. redocly.yaml configures the documentation engine, sidebars.yaml describes the navigation tree, top-nav.yaml the header, redirects.yaml the URL history, and translations.yaml the localisation setup. A redirect file is the mark of a site that has lived long enough to have moved pages, and its presence alongside a blog suggests this one has. There are also files that read as in-progress design work rather than finished infrastructure: button-demo.page.tsx, link-demo.page.tsx, icon-demo.page.tsx, CSS-OPTIMIZATION.md, CSS-OPTIMIZATION-SUMMARY.md, COLOR-MIGRATION-SUMMARY.md and a brand update handoff outline. A documentation repository that keeps its sketches in the open is easier to contribute to than one that hides them.

## Four commands to a local preview of the whole site

The build is Redocly, and the README's local setup is a numbered list you can follow without inference. Node.js and NPM must be installed first, and the README says the site is tested with the current LTS release of each, which is a narrower requirement than newest and a looser one than any particular pinned version.

Clone and enter the directory, then install the engine and switch branches before starting the server:

```bash
git clone git@github.com:XRPLF/xrpl-dev-portal.git && cd xrpl-dev-portal
```

```bash
npm install @redocly/realm
```

```bash
git switch master
```

```bash
npm start
```

That last one is worth reading in package.json, where the start script is realm develop. The engine is pinned rather than floated: @redocly/realm at 0.137.0 and @redocly/theme at 0.69.0, exact versions rather than carets. For a site whose output is the authoritative documentation for a financial network, pinning the renderer is defensible. Pinning it also means the engine moves only when someone deliberately bumps it.

The step order is not arbitrary. git switch master comes after the install rather than before, which reads as an instruction for people who arrive from a fork where the default branch differs, and defaultBranch on the repository is master.

## The CSS pipeline explains why styles are hard to change here

package.json carries far more than the start script. build-css runs three tools in sequence: sass compiles styles/xrpl.scss with two load paths into a temporary file, postcss processes that temporary file with NODE_ENV set to production into static/css/devportal2024-v1.css, and then the temporary file is removed. The dev variant drops NODE_ENV and adds a source map, and the watch variant adds --watch plus a list of silenced deprecations covering import, global-builtin and color-functions.

That silenced deprecation list is a description of the project's technical debt in one line. Sass has been deprecating @import in favour of the module system, has deprecated the global built-in functions that got moved into sass:math, and has deprecated the old color function signatures. Rather than migrate, the watch script silences the warnings so real ones stay visible. A newcomer will see a warning-free build and reasonably conclude the styles are clean, which is not quite what the flags mean.

Alongside the build scripts sit three audit scripts that are not part of the build: analyze-css, button-audit and contrast-check. A contrast checker in a repository whose README points at a Code of Conduct and a colour migration summary is a documentation site taking accessibility seriously as a build-time concern. The presence of lottie-react and moment as dependencies also tells you the site animates and formats dates, both of which are costs in a build that has to run in CI and a source of bugs that do not show up in the markdown.

## Translations live in @l10n, and only one of them is published

The localisation story is short and specific. Documentation in this repository is created in English first, then translated into other languages by community contributors. Currently, only the Japanese translations are live on the site, and Spanish translation efforts are incomplete and not actively used.

The structure supports the claim. A directory named @l10n sits at the repository root, and the README links a Japanese CONTRIBUTING.md and a Japanese Code of Conduct from within it, which means the translated repository carries translated governance documents and not only translated prose. The topic tags on the repository include xrpl-py and xrpljs alongside the protocol names, which is a small hint that the docs and the libraries are treated as one audience.

The process documentation is external rather than local. For information on adding and maintaining translated files, the README points to a page on xrpl.org about documentation translations, under resources and contribute-documentation. So the rules live on the site that this repository builds, which is convenient for readers and a little circular for contributors who have not got the site running yet. The Japanese setup suggests the intended model is a full parallel tree rather than per-file strings, and that model is what makes an incomplete Spanish effort a real maintenance liability rather than a cosmetic gap.

## Where to file an issue, and what the six board columns mean

The README splits issue reporting by subject with a precision worth copying. Bugs, feature requests and suggestions for the XRP Ledger documentation or the xrpl.org website go to GitHub Issues in this repository. Anything about xrpld or rippled, about Clio, or about the client libraries including xrpl.js and xrpl-py belongs in the respective source repository under the XRPLF organisation.

That boundary matters more than it first appears. The documentation describes all of those components, so a bug report about a library is filed against the docs repository by someone who reasonably read the docs page describing the bug. The routing instruction is the fix, and it is one sentence.

Contributors are asked to plan and track work in GitHub Projects, using the xrpl-docs Kanban board. The README then defines its six columns in detail, which is unusual specificity for a README and suggests the board is the actual workflow rather than a suggestion. No Status means new or existing issues nobody has triaged yet. Backlog means work to be done eventually, and the definition adds a quality bar: such issues should contain actionable and helpful information for a contributor to work on. Planned means an assignee intends to address it in the near future, given as two to four weeks. In Progress means a contributor is actively working. In Review means a proposed fix is under review, and those issues should be associated with an open pull request. Done means the work is complete and the related content updates have been merged.

Two things follow from reading the columns closely. An issue without a status has not been rejected, it has not been looked at, and the Backlog definition sets the bar for what makes an issue worth leaving there. The final column ties the board to pull requests, so the documentation review process runs through code review.

## The license field and the release history do not agree

There is an inconsistency here and it is easy to resolve by reading the right file. package.json declares "license": "MIT", and the repository contains a LICENSE file at its root. GitHub itself reports no license type for the repository, the NOASSERTION value that usually means the license file was not detected or recognised. Unlike some projects, the two sources do not contradict each other, they simply disagree about whether a licence was found. The README also points to a CODE-OF-CONDUCT.md and a CONTRIBUTING.md, each with a Japanese counterpart in @l10n.

The release history is older than the activity. Three tagged releases are visible: v2015-01-12 published on 2015-01-13, v2014-10-30 on 2014-10-30 and v2014-10-27 on 2014-10-27. Those are from the era when a documentation repository shipped versioned snapshots for the documentation itself. Nothing since, which is not a problem for a documentation site where deploys come from master, but it does mean there is no changelog to read and no version history to diff. The most recent push was on 2026-09-28.

What the repository does not tell you is how a breaking change to a documented API gets communicated, since there is no release channel for the docs themselves. For a reader who depends on a documented behaviour, the practical answer is to depend on the code in a specific repository at a specific commit rather than on the website, and to treat the website as the place to look things up rather than as a versioned interface.

## Conclusion

This repository is the right place to look if you want to know what the XRP Ledger documentation actually claims, because the site is generated from it and the markdown is readable without running anything. It is equally the right place to contribute, since the README routes documentation issues here and everything else elsewhere. Two practical notes before you start. First, the build expects the master branch and the current Node.js LTS release, and the CSS pipeline is Sass plus PostCSS with an explicit intermediate file, so a change to styling touches two tools and a temp path. Second, licensing is unclear: the package.json declares MIT while GitHub reports no license type, so read the LICENSE file yourself if you plan to reuse content or code. The Japanese translation is live and Spanish is incomplete, which means a contribution to a non-English version may have no visible destination yet. Pick an issue off the xrpl-docs board so your work is visible to reviewers, follow the Code of Conduct linked from the README, and expect the review cycle the six board columns describe. The most recent push was on 2026-09-28.

## FAQ

### What is XRPL and what does this repository contain?

XRPL is the XRP Ledger, and this repository holds the source for xrpl.org, including the developer documentation for the core server, the client libraries and other open-source XRP Ledger software. It contains the reference docs, the public about and community pages, the blog, API examples and code samples, the navigation and redirect configuration, and the translations. The site is built and published with Redocly.

### How do I build and preview xrpl.org locally?

Install Node.js and NPM, using the current LTS release of each, then clone the repository and run npm install @redocly/realm, git switch master and npm start. The start script in package.json is realm develop, and the engine is pinned at version 0.137.0 with the theme at 0.69.0. Style changes go through a separate pipeline of Sass then PostCSS via the build-css scripts.

### Where should I report a bug in XRP Ledger?

It depends on the component. Bugs and suggestions about the documentation or the xrpl.org website go to GitHub Issues in this repository. Issues about xrpld or rippled, Clio, or the client libraries including xrpl.js and xrpl-py go to the respective source repository under the XRPLF organisation. Contributors should track their work on the xrpl-docs Kanban board and keep the issue status current as it moves through its six columns.

### Which languages is the XRPL documentation available in?

English is the source language and translations are contributed by community members. At present only the Japanese translations are live on the site; the Spanish translation effort is described as incomplete and not actively used. Translated files live under the @l10n directory, which also holds Japanese versions of the contribution guidelines and the Code of Conduct. The process for maintaining translations is documented on the site itself.

### What license applies to the XRP Ledger documentation?

The answer requires reading the file rather than trusting the metadata. package.json declares MIT and a LICENSE file exists at the repository root, while GitHub reports no detected license type for the repository, which is the NOASSERTION value. There are no tagged documentation releases since 2015, so the website is the distribution channel rather than a versioned artifact. If you intend to reuse material, confirm the licensing from the LICENSE file directly.

## Sources

- [Issues](https://github.com/XRPLF/xrpl-dev-portal/issues)
- [Project website](https://xrpl.org)
- [README](https://github.com/XRPLF/xrpl-dev-portal/blob/master/README.md)
- [Releases](https://github.com/XRPLF/xrpl-dev-portal/releases)
- [XRPLF/xrpl-dev-portal on GitHub](https://github.com/XRPLF/xrpl-dev-portal)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xrplf-xrpl-dev-portal