PostHog User Management | OpsBlu Docs

PostHog User Management

Manage team access, roles, and permissions in PostHog for collaborative analytics

PostHog user management controls who can access your analytics data, create insights, manage feature flags, and configure project settings. Whether you're on PostHog Cloud or self-hosted, access control follows a consistent model: organizations contain projects, users have organization-level roles, and project-level permissions determine what they can do.

Access Management at a Glance

How PostHog Organizes Access

Organizations:

  • Top-level entity that contains projects
  • Billing and subscription managed at organization level
  • Users invited to organization, then granted access to specific projects

Projects:

  • Individual PostHog instances (e.g., "Production", "Staging", "Development")
  • Each project has its own data, API keys, and settings
  • Users can access multiple projects within an organization

Roles:

  • Organization-level roles control billing and organization settings
  • Project-level roles determine permissions within each project
  • Users can have different roles across different projects

Organization Roles

Owner:

  • Full control over organization
  • Manage billing and subscription
  • Create and delete projects
  • Invite and remove users
  • Delete organization
  • Limit: Typically 1-2 per organization

Admin:

  • Create and configure projects
  • Invite users to organization
  • Manage organization settings
  • Cannot manage billing
  • Cannot delete organization

Member:

  • Access granted projects
  • No organization-level permissions
  • Project permissions determined by project role

Project Roles

Admin:

  • Full project access
  • Configure project settings
  • Manage feature flags and experiments
  • Create and delete dashboards
  • Invite users to project
  • Manage data retention and deletion

Member:

  • Create insights, dashboards, and cohorts
  • View and use feature flags
  • Track events and view recordings
  • Cannot modify project settings
  • Cannot invite users

Viewer (read-only):

  • View dashboards and insights
  • Watch session recordings
  • Cannot create or modify content
  • Cannot configure settings

Typical Access Structure

Early-stage startup (5-10 people):

  • 1 Owner (founder/CTO)
  • 2-3 Admins (engineering leads)
  • Rest as Members

Growing company (50+ people):

  • 1-2 Owners (CTO, VP Engineering)
  • 5-10 Admins (engineering managers, product leads)
  • Product managers and analysts as Members
  • Executives and stakeholders as Viewers

Enterprise (hundreds of employees):

  • 2-3 Owners (CTO, VP Engineering, VP Product)
  • 20+ Admins (department leads)
  • Analysts, PMs, engineers as Members
  • Executive team as Viewers
  • External contractors with limited project access

Project Separation Strategy

By environment:

Organization: Acme Corp
├── Project: Production
├── Project: Staging
└── Project: Development

By product:

Organization: Acme Corp
├── Project: Web App
├── Project: Mobile App
└── Project: Marketing Site

By customer segment:

Organization: Acme Corp
├── Project: Enterprise Customers
├── Project: SMB Customers
└── Project: Internal Tools

By team:

Organization: Acme Corp
├── Project: Product Team
├── Project: Marketing Team
└── Project: Customer Success Team

Access Control Best Practices

Principle of least privilege:

  • Grant minimum access needed for role
  • Default to Member, upgrade to Admin only when necessary
  • Use Viewer role for stakeholders who need visibility, not control

Project-based access:

  • Don't grant access to all projects by default
  • Production data should have stricter access controls
  • Development/staging can be more permissive

Regular audits:

  • Review user list quarterly
  • Remove users who have left the company
  • Downgrade access for users who changed roles
  • Document why each user has access

Separation of concerns:

  • Keep production and development projects separate
  • Limit production access to engineers actively on-call
  • Marketing and sales teams don't need access to internal analytics

External collaborators:

  • Create separate projects for external access if possible
  • Use Viewer role for consultants unless they need to create content
  • Set expiration dates for contractor access
  • Document the scope and duration of access

Single Sign-On (SSO)

PostHog Cloud Enterprise plans support SSO via:

  • SAML 2.0 (Okta, Azure AD, Google Workspace)
  • OAuth (GitHub, Google, GitLab)

Benefits:

  • Centralized access control
  • Automatic provisioning/deprovisioning
  • Enforce company authentication policies
  • Single logout across all tools

Configuration:

  1. Contact PostHog support to enable SSO
  2. Provide identity provider metadata
  3. Configure attribute mapping
  4. Test with a small group before rolling out

Self-hosted: SSO configuration available in instance settings. Refer to PostHog self-hosted documentation for IdP-specific guides.

API Access & Service Accounts

Personal API keys:

  • Used for programmatic access
  • Tied to individual user account
  • Inherits user's permissions
  • Rotatable in user settings

Project API keys:

  • Used for SDK initialization and event ingestion
  • Public (safe to expose client-side)
  • One per project
  • Rotatable in project settings

Best practices:

  • Use project API keys for client-side SDKs
  • Use personal API keys for backend integrations
  • Rotate keys if compromised
  • Don't commit API keys to version control
  • Use environment variables for API keys

Audit Logging

PostHog Cloud (Enterprise):

  • Full audit log of user actions
  • Track who created, modified, or deleted resources
  • Export logs for compliance

Self-hosted:

  • Logs available in PostHog admin panel
  • Configure log retention
  • Export to SIEM if needed

What's logged:

  • User invitations and removals
  • Role changes
  • Project creation/deletion
  • Settings modifications
  • Data exports
  • Feature flag changes

Compliance & Data Access

GDPR:

  • Users can request data deletion
  • PostHog provides tools for data subject requests
  • Configure data retention policies

Data residency:

  • PostHog Cloud offers US and EU hosting
  • Self-hosted keeps all data in your infrastructure

Access controls for sensitive data:

  • Use projects to separate sensitive data
  • Limit access to projects with PII
  • Enable session recording masking for sensitive fields
  • Configure autocapture to exclude sensitive elements

Team Collaboration Features

Shared dashboards:

  • Create dashboards visible to entire team
  • Pin important dashboards for easy access
  • Subscribe to dashboard updates via Slack

Insight sharing:

  • Share insights via URL
  • Embed insights in wikis or tools
  • Export data for reports

Annotations:

  • Mark deployments, incidents, or campaigns
  • Visible across all project insights
  • Helps correlate events with metric changes

Comments (Enterprise):

  • Discuss insights directly in PostHog
  • Tag team members
  • Keep context with the data

Governance & Documentation

Maintain access documentation:

# PostHog Access Registry

## Owners
- jane@example.com (CTO)
- john@example.com (VP Engineering)

## Admins
- alice@example.com (Engineering Manager)
- bob@example.com (Product Lead)

## Members
- charlie@example.com (Senior Engineer)
- diana@example.com (Product Manager)
- evan@example.com (Data Analyst)

## Viewers
- ceo@example.com (CEO)
- cmo@example.com (CMO)

## External Access
- consultant@agency.com (Marketing Consultant, expires 2024-06-01)

Access request process:

  1. Request access via ticket/form
  2. Manager approves
  3. Admin grants access
  4. Document in access registry
  5. Set review date (quarterly or at project end)

Offboarding checklist:

  • Remove from organization
  • Revoke API keys
  • Transfer ownership of insights/dashboards
  • Document removal in access registry
  • Remove from shared Slack channels

Platform Notes

PostHog Cloud:

  • User management via Settings → Organization
  • Invite users via email
  • SSO available on Enterprise plan
  • Billing managed by organization Owners

Self-hosted:

  • User management via admin panel
  • Create users or enable SSO
  • Configure authentication methods
  • Manage license keys

Linked Runbooks

Detailed guides for specific user management tasks:

Common Scenarios

New engineer joins:

  1. Add to organization as Member
  2. Grant Member access to Development project
  3. Grant Member access to Staging project
  4. Grant Viewer access to Production project (initially)
  5. Upgrade to Member for Production after onboarding

Product manager needs access:

  1. Add to organization as Member
  2. Grant Member access to all projects
  3. Provide onboarding on creating insights
  4. Add to relevant Slack channels for alerts

Executive needs visibility:

  1. Add to organization as Member
  2. Grant Viewer access to Production project
  3. Share key dashboards
  4. Set up weekly email digest

Contractor engagement:

  1. Add to organization as Member
  2. Grant access only to specific project
  3. Set reminder for access expiration date
  4. Document scope in access registry
  5. Remove promptly when engagement ends

Need help? Contact PostHog support or refer to PostHog access control documentation.

Back to top