PostHog Handbook Library / Engineering

472 words. Estimated reading time: 3 min.

How PostHog.com works

PostHog.com is built and maintained in-house by the . You've probably never seen a Gatsby.js site like this before. Eli Kinsey is the mastermind behind how the site is structured.

For more context, read why we designed our website to look like an operating system.

The "operating system"

  1. At the top level, gatsby-browser.tsx loads ``
  2. `` renders the chrome of the "operating system"
  3. `` – the MacOS-style menu bar
  4. `` – the desktop app icons and desktop background
  5. `` – the chrome for each app and where the content renders
  6. ``
  7. ` loads and `.

The apps

Each "app" is simply a page like a normal Gatsby site. There are a handful of apps:

  1. `` – used for all long-form content like the docs, handbook, blog
  2. `` – a WYSIWYG page editor
  3. `` – an OS-style file explorer
  4. `` – an email-like app
  5. `` – a slide deck

Each app can reference shared components like `` which contains the necessary navigational elements (like the back button, search, and filters).

Let's look at a product page to see how it uses the `` template.

Example: posthog.com/session-replay

This page (/src/pages/session-replay/index.tsx) includes two critical pieces:

  1. `` – the views where the content will display
  2. Defines the PRODUCT_HANDLE
  3. Specifies which slides should appear in this presentation using createSlideConfig

` loads up all the various templates needed (like , , ) and sources the content using the useProduct` hook.

useProduct hook

Each product's data is defined in a JSON file like:

/src/hooks/productData/session_replay.tsx

When the session_replay handle is passed into useProduct, it looks up the product's data like:

Note: The maintains a billing API that contains pricing tiers and entitlements. This is how pricing data and usage tiers stay in sync between the website and product. The plan is to eventually move the product data into the billing API so there's a single source of truth for every product.

---

Services we use

| Service | Purpose | | ------------- | ------------------------------------------------------ | | Vercel | Hosting | | Gatsby | Static site framework | | GitHub | Source code repository | | Ashby (API) | Applicant tracking system | | Algolia (API) | Site search | | Strapi | Headless CMS for community profiles and changelog data | | PostHog | Analytics, feature flags | | Inkeep | AI-powered community answers |

Image: Diagram of PostHog.com

Website content is stored in two places:

  1. Markdown/MDX files (in the GitHub repo) - _most website content_
  1. Strapi - _user-generated content_

Canonical URL: https://posthog.com/handbook/engineering/posthog-com/how-posthog-website-works

GitHub source: contents/handbook/engineering/posthog-com/how-posthog-website-works.mdx

Content hash: 3b74f7beceace9b0

Static reader notes
  • MDX_COMPONENT_STATIC_ADAPTER: Adapted interactive MDX components for static reading: AppWindow, CookieBannerToast, CustomersSlide, Desktop, Editor, Explorer, FeaturesSlide, HeaderBar, Inbox, OverviewComponent, Presentation, ReaderView, SlidesTemplate, SmallTeam, TaskBarMenu, TeamMember, WindowContainer, WindowProvider, Wrapper.