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` `.

- This contains the window's top bar with the minimize, maximize, and close buttons. It also supports window resizing.
- Inside here is where the contents of each app renders

### 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:

- icon
- color
- category
- SEO data
- screenshots array
- feature customers
- features array
- feature comparison chart
- etcc

> 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_

- Docs, handbook, most pages

1. Strapi - _user-generated content_

- Community forum posts, community profiles

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.