neilbryson / docs

Documentation for all Ory products

Home Page:

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ory Documentation

Chat | Newsletter

Documentation | Support this project!

Work in Open Source, Ory is hiring!

Ory Documentation

Documentation is the single source of truth

The Ory documentation is the place to find all information related to Ory services, usage and troubleshooting.

This repository contains meta-documentation for the Ory Ecosystem. You can find the source code for each project here:

Other Ory Projects documentation:



The Ory Developer documentation can be organized in three different main categories:

  • Concepts
    • The purpose of this category is to give the reader a deep understanding of the ideas upon which the project is built. Content in this category has the form of a discursive explanation. The main goal is to explain.
  • Guides
    • The purpose of this category is to solve a specific problem. It has the form of a series of steps towards a goal. It's aimed towards more experienced users, who are already familiar with the concepts and tools
  • Reference
    • The purpose of this category is to provide a detailed & in-depth description of the project. It has the form of an austere and to the point explanation and is rooted in code, most often these documents are built directly from code without editor interaction. It doesn't give information on how to do specific things.

There are also sub-types:

  • Introduction
    • The purpose of this guide is to introduce the very basics of the project and give newcomers an easy way to start. Contains the most basic explanation of the project, an installation guide or a Quickstart/5-Minute Tutorial.
  • Troubleshooting
    • Contains instructions on how to resolve issues with Ory services.

Document frontmatter

Add a meaningful title and an ID to the top of the document. id needs to be separated with - and lowercase, title with space and Uppercase. Example:

id: documentation-id
title: Documentation Title


Ory documentation should be clear and easy to understand.

  • Avoid unnecessary words.
  • Be clear, concise, and stick to the goal of the topic.
  • Write in US English with US grammar.
  • Use articles such as a/an and the wherever possible.
  • Use active voice.
  • Avoid slang and jargon, while allowing for specific terminology.


  • Use sentence case for headings.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > h4
  • Avoid using symbols and special characters in headers. Whenever possible, they should be plain and short text.
  • Leave one blank line before and after a heading.
  • Don't use links in headings.
  • Search engines prioritize words used in headings and subheadings. Make your subheading titles clear, descriptive, and complete to help users find the right example, as shown in the section on heading titles.
Headings capitalization

Names for console UI elements


  • Always start list items with a capital letter, unless they're parameters or commands that are in backticks, or similar.
  • Always leave a blank line before and after a list.
  • Begin a line with spaces (not tabs) to denote a nested sub-item.
  • Indent all code blocks in lists so that they are formatted to be part of list items.


Playwright tests

The Playwright (E2E) tests file names end with .spec.ts and can be found in /tests/playwright. Node.js is required to run Playright tests locally. To test the documentation locally:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

All documents and other files in this repository must be formatted with Prettier using the Ory Prettier styles.

The recommended way to achieve this is installing the Prettier plugin for your editor:

To format all relevant files, run these commands from the main directory of the repository:

make format
git commit -a -m "styles: format"
git push



  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed. `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docs markdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files! cd docs markdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How to...

Add content to Examples page

The Examples page provides an overview of Ory examples. Add a new example or modify existing entries:

  • Open examples-content.tsx under the path docs/src/pages/_assets/
  • Copy the following snippet and append it in the correct array (either official, community or self-hosting examples):
      title: 'Protect a Page with Login: NextJs/React', //Your example title goes here
      language: 'typescript',                           //The main programming language of your example
      author: 'ory',                                    //The author's GitHub handle
      tested: true,                                     //Is the example in ory/examples or ory/docs and has automated tests?
      repo: '', //The repo containing the example code
      docs: ''                        //Documentation for the example, can be README, blog article or similar
  • language can be one of: dart, django, docker, erlang, flutter, go, java, javascript, kotlin, kubernetes, nextjs, nodejs, ory, php, python, react, rescript, svelte, typescript, vue

  • Open a pull request with your changes.

Links to other pages

If you would add a link to an outside resource, just go ahead.

If you want to add a link to a document in our own documentation, add the filename.

  • [XY Guide](./guide/
  • 🚫 [XY Guide](./guide/XY)

This prevents broken links issue when you load the documentation from an outside link.

Import Markdown

Use the same markdown in several places:

import ExampleMarkdown from './_common/'

<ExampleMarkdown />

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

id: documentation id
title: Documentation Title

import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

  lang="js" # the language of the code you want to add e.g. jsx,tsx,ts,go,yaml,yml,js,html,pug


You can use startAt and endAt if you only want to show a part of the code:


From this repository

Use the same code example in several places:

import CodeBlock from '@theme/CodeBlock'
import exampleJs from '!!raw-loader!./code-example.jsx'
import exampleGo from '!!raw-loader!./code-example.go'

<CodeBlock className="language-jsx">{exampleJs}</CodeBlock>
<CodeBlock className="language-go">{exampleGo}</CodeBlock>

Code examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

import CodeBlock from '@theme/CodeBlock'

    {label: 'UI', value: 'ui'},
  <TabItem value="ui">
    <CodeBlock className="language-jsx">{`Your


  <TabItem value="node">
  <TabItem value="html">

Shell examples

Use shellsession:

npx create-next-app@latest --typescript
npm i --save @ory/integrations

Please do not prefixes with $

- $ command --arg # do not
+ command --arg # do


Add images directly with an img tag:

  alt="Image description which will be the alt tag"

The useBaseUrl is and exposes src/static/..., so all images are stored in src/static/images/....

Compress new images you add to the documentation. One known tool is pngquant. Related article.

  • Don't use lorem ipsum text.
  • Capture only the relevant UI.


When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. Please make sure that no history or auto-suggestions are visible.

Once recorded, use the commands below to convert them to mp4 and webm:


ffmpeg -i $file -an -c:v libvpx-vp9 -vf scale=1024:-1 -crf 30 -b:v 0 "${file%.*}".webm
ffmpeg -i $file -vcodec h264 -vf scale=1024:-1 -an "${file%.*}".mp4

Next copy them next to the markdown file you are editing. Then use the following code to display the video:

import mp4 from './screencast.mp4'
import webm from './screencast.webm'
import VideoEmbed from '@site/src/components/VideoEmbed'

<VideoEmbed mp4={mp4} webm={webm} />

To embed Youtube videos just copy & paste the link, it's that easy!

CLI documentation

Fixing autogenerated Ory CLI docs

If you find an error in the Ory CLI documentation here are some pointers on how to fix it:

The code that generates the CLI docs (for Kratos) comes from here:

cmd/clidoc/main.go is the general path for all Ory projects.

The command to generate the CLI docs can be found here:


Documentation for all Ory products

License:Apache License 2.0


Language:JavaScript 52.3%Language:TypeScript 26.4%Language:CSS 6.7%Language:HTML 3.5%Language:Go 2.8%Language:Dart 2.3%Language:Vue 2.2%Language:Shell 1.2%Language:PHP 1.0%Language:Makefile 1.0%Language:Swift 0.2%Language:Pug 0.1%Language:Dockerfile 0.1%Language:Kotlin 0.1%Language:Objective-C 0.0%