Onboarding docs
Contents
Onboarding docs, or product installation docs, are special because these instructions are shared between the in-app onboarding flow and the getting started pages on the posthog.com website.
These are some of the first pieces of docs a new user will see. They show users how to quickly set up and install a product, so they need to be up to date and accurate.
To help keep in-app and website onboarding docs in sync, there is a single source of truth for the onboarding docs in the posthog/posthog repository under the docs/onboarding directory. This means you only need to update the in-app onboarding docs in the PostHog monorepo, and the website docs will be updated automatically.
Which products have shared onboarding docs
This is a relatively new feature, so we're still migrating old onboarding docs to the new system. As of February 2026:
| Product | Status |
|---|---|
| LLM analytics | ✅ Migrated |
| Product analytics | ✅ Migrated |
| Web analytics | ⏳ In progress |
| Session replay | ✅ Migrated |
| Feature flags | ✅ Migrated |
| Experiments | ✅ Migrated |
| Error tracking | ⏳ Not yet migrated |
| Surveys | ⏳ In progress |
| Data pipelines | ⏳ Not yet migrated |
| Data warehouse | ⏳ Not yet migrated |
| Revenue analytics | ⏳ Not yet migrated |
| PostHog AI | ⏳ Not yet migrated |
| Workflows | ⏳ Not yet migrated |
| Logs | ⏳ Not yet migrated |
| Endpoints | ⏳ Not yet migrated |
How it all works
Onboarding content is written once as React components in the posthog/posthog repo, then rendered in two places:
- PostHog monorepo: For in-app onboarding, the PostHog app imports these docs components directly and wraps them with
OnboardingDocsContentWrapper, which provides UI components likeSteps,CodeBlock, etc. - Posthog.com repo: The website pulls the docs components from the monorepo via
gatsby-source-git, a Gatsby plugin, and then renders them through MDX stub files that use a similar but differentOnboardingContentWrapperto provide compatible UI components.
Both wrappers provide the same component names (Steps, CodeBlock, CalloutBox, etc.) so the shared content renders correctly in either place. When you merge changes to master in posthog/posthog, the website automatically pulls the updated content on its next build.
If you need some help with structuring your files, this is the architecture for each repo:
For a complete working example, see the Session Replay implementation:
| Repo | File |
|---|---|
| posthog/posthog | docs/onboarding/session-replay/ |
| posthog.com | react.mdx |
| posthog.com | sr-installation-wrapper.tsx (single file with all wrappers) |
How to create/migrate new onboarding docs
Step 1: Create the shared component in posthog/posthog
Navigate to the product directory in
docs/onboarding/. If it doesn't exist, create it:docs/onboarding/your-product/Create a new
.tsxfile:docs/onboarding/your-product/filename.tsxExport a step function and Installation component. Use
createInstallationto automatically handle the rendering:docs/onboarding/feature-flags/python.tsxKey patterns- You can reuse installation steps from product analytics by calling their step function with the same context.
- Step badges include
required,optional, orrecommended.
For reusable snippets, create them in
docs/onboarding/<product>/_snippets/and export a named component.Create the in-app wrapper in
frontend/src/scenes/onboarding/sdks/your-product/. Use thewithOnboardingDocsWrapperhelper:frontend/src/scenes/onboarding/sdks/feature-flags/FeatureFlagsSDKInstructions.tsxTest in the app by running the monorepo locally and navigate to
localhost:8010/onboarding. From this page, you can select your product and test.
Step 2: Create the website stub in posthog/posthog.com
To test your changes locally, temporarily edit
gatsby-config.jsto point to your branch:JavaScriptDon't forget to revert this change!Do not merge changes to `gatsby-config.js` that point to a non-master branch. This is only for testing.Create a single TSX wrapper file at
contents/docs/<product>/installation/_snippets/<prefix>-installation-wrapper.tsxthat exports all SDK wrappers:contents/docs/session-replay/installation/_snippets/sr-installation-wrapper.tsxThe
modifyStepsprop lets you add website-specific steps (like "Next steps") that aren't needed in-app.Create an MDX stub file for each SDK at
contents/docs/<product>/installation/<name>.mdx:contents/docs/session-replay/installation/react.mdxTest locally: Run
pnpm startand verify the page renders correctly at the expected URL.Commit and merge both the
posthog/posthogandposthog/posthog.comPRs.