integration-astro-hybrid

name	integration-astro-hybrid
description	PostHog integration for Astro hybrid rendering with both static and server-rendered pages
metadata	{"author":"PostHog","version":"1.27.0"}

PostHog integration for Astro (Hybrid)

This skill helps you add PostHog analytics to Astro (Hybrid) applications.

Workflow

Follow these steps in order to complete the integration:

1. references/1-begin.md - PostHog Setup - Begin ← Start here
2. references/2-edit.md - PostHog Setup - Edit
3. references/3-revise.md - PostHog Setup - Revise
4. references/4-conclude.md - PostHog Setup - Conclusion

Reference files

• references/EXAMPLE.md - Astro (Hybrid) example project code
• references/1-begin.md - Start the event tracking setup process by analyzing the project and creating an event tracking plan
• references/2-edit.md - Implement PostHog event tracking in the identified files, following best practices and the example project
• references/3-revise.md - Review and fix any errors in the PostHog integration implementation
• references/4-conclude.md - Review and fix any errors in the PostHog integration implementation
• references/astro.md - Astro - docs
• references/identify-users.md - Identify users - docs

The example project shows the target implementation pattern. Consult the documentation for API details.

Key principles

• Environment variables: Always use environment variables for PostHog keys. Never hardcode them.
• Minimal changes: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.
• Match the example: Your implementation should follow the example project's patterns as closely as possible.

Framework guidelines

• Always use the is:inline directive on PostHog script tags to prevent Astro from processing them and causing TypeScript errors
• Use PUBLIC_ prefix for client-side environment variables in Astro (e.g., PUBLIC_POSTHOG_PROJECT_TOKEN)
• Create a posthog.astro component in src/components/ for reusable initialization across pages
• Import the PostHog component in a Layout and wrap all pages with that layout
• Use posthog-node in API routes under src/pages/api/ for server-side event tracking
• Store the posthog-node client instance in a singleton pattern (src/lib/posthog-server.ts) to avoid creating multiple clients
• In Astro 5, use output static (the default) with an adapter - pages are prerendered by default
• Use export const prerender = false to opt specific pages into SSR when they need server-side rendering
• Only pages that need server-side PostHog tracking (like API-backed forms) should opt out of prerendering
• Remember that source code is available in the node_modules directory
• Check package.json for type checking or build scripts to validate changes
• When a reverse proxy is configured, both /static/* AND /array/* must route to the assets origin (us-assets.i.posthog.com or eu-assets.i.posthog.com).
• posthog-js is the JavaScript SDK package name
• posthog.init() MUST be called before any other PostHog methods (capture, identify, etc.)
• posthog-js is browser-only — do NOT import it in Node.js or server-side contexts (use posthog-node instead)
• Autocapture is ON by default with posthog-js (tracks clicks, form submissions, pageviews). Do NOT disable autocapture unless the user explicitly requests it.
• NEVER send PII in posthog.capture() event properties — no emails, full names, phone numbers, physical addresses, IP addresses, or user-generated content
• PII belongs in posthog.identify() person properties (email, name, role), NOT in capture() event properties
• Call posthog.identify(userId, { email, name, role }) on login AND on page refresh if the user is already logged in
• Call posthog.reset() on logout to unlink future events from the current user
• For SPAs without a framework router, capture pageviews with posthog.capture($pageview) or use the capture_pageview history_change option in init for History API routing
• posthog-node is the Node.js server-side SDK package name – do NOT use posthog-js on the server
• Include enableExceptionAutocapture: true in the PostHog constructor options
• Add posthog.capture() calls in route handlers for meaningful user actions – every route that creates, updates, or deletes data should track an event with contextual properties
• Add posthog.captureException(err, distinctId) in the application's error handler (e.g., Express error middleware, Fastify setErrorHandler, Koa app.on('error'))
• In long-running servers, the SDK batches events automatically – do NOT set flushAt or flushInterval unless you have a specific reason to
• For short-lived processes (scripts, CLIs, serverless), set flushAt to 1 and flushInterval to 0 to send events immediately
• Reverse proxy is NOT needed for server-side Node.js – only client-side JavaScript needs a proxy to avoid ad blockers

Identifying users

Identify users during login and signup events. Refer to the example code and documentation for the correct identify pattern for this framework. If both frontend and backend code exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to maintain correlation.

Error tracking

Add PostHog error tracking to relevant files, particularly around critical user flows and API boundaries.