Self-Hosted PostHog Analytics on GCP VM

The Problem and Why It Mattered

I deployed a self-hosted PostHog analytics instance on a GCP Compute Engine VM and integrated it with both a Flutter mobile app and a Next.js web app — keeping all product analytics data within our own GCP infrastructure. The relevant technical and business risk is the cost of leaving this workflow, control, or product boundary unclear, manual, insecure, or difficult to operate. The case study focuses on the decisions used to make that risk manageable.

Objectives and Success Criteria

• Deliver the capability described in the project objective using a maintainable technical design.
• Make the main workflow, control boundary, and operational responsibilities explicit.
• Produce reviewable implementation evidence without publishing confidential values or customer data.

Requirements and Constraints

The product design had to balance a clear user workflow with maintainable technical boundaries, secure handling of user data, and a path for incremental delivery.

My Role and Ownership

I owned the technical design and implementation described in this portfolio record, including the technology choices, core system boundaries, and the documentation of the resulting approach. Related organisational decisions, vendor operations, and formal certification decisions remain outside the scope of this technical case study unless stated explicitly.

Solution Overview

The solution is built around PostHog, Compute Engine, Cloud SQL. Its implementation is organised as the components below so that the architecture, control points, and operating model can be evaluated separately rather than treated as a list of tools.

Architecture and System Design

The public architecture description follows the path from the initiating user, workload, or operator action through the relevant product intelligence components. Access boundaries, data or state handling, and operational controls are described at a safe level; secrets, private addresses, and client-sensitive implementation details are intentionally omitted.

Technology Decisions and Trade-Offs

I selected PostHog, Compute Engine, Cloud SQL because they support the project objective and make the critical engineering boundaries explicit. The trade-off is operational and platform complexity: the design depends on documented configuration, controlled access, and ongoing review rather than assuming that a managed service or framework removes engineering responsibility.

Implementation Walkthrough

The following implementation notes describe the components that matter most to the project outcome. They are intentionally focused on technical decisions and operating behaviour instead of reproducing entire source files or sensitive configuration.

Implementation: Infrastructure Setup

e2-standard-2 Compute Engine VM running Ubuntu 22.04 in a private VPC subnet, fronted by an Nginx reverse proxy handling TLS termination. PostHog Community Edition runs as Docker Compose, with PostgreSQL on Cloud SQL and Redis on Cloud Memorystore.

Implementation: Flutter Mobile App Integration

Integrated the PostHog Flutter SDK pointing at the self-hosted instance. Event taxonomy: screen views with route names and user properties, feature interaction events, error events with stack trace context, session recording opt-in for staging debugging.

Implementation: Next.js Web App Integration

PostHog JavaScript SDK with SSR compatibility. Consent-gated initialisation: PostHog only initialises after the user accepts analytics cookies. Session recording with automatic PII redaction for password inputs and email fields.

Implementation: Unified Cross-Platform Dashboard

Feature adoption by platform (mobile vs. web), drop-off funnels that follow users across both surfaces, retention cohort analysis by acquisition source. PostHog group analytics aggregate events at the organisation level for B2B product metrics.

Implementation: Persistent Storage & Maintenance

All event data persists in Cloud SQL — not local VM disk. Automated Cloud SQL backups with 30-day retention. PostHog and application logs stream to Cloud Logging via the Ops Agent.

Implementation: Results

100% of analytics data stored within GCP. Cross-platform funnel analysis revealed mobile users convert to paid 2.3× faster than web users. Self-hosting cost: ~$45/month vs. PostHog Cloud equivalent at ~$450/month.

Challenges, Failures and Corrections

This portfolio record does not invent deployment failures, client incidents, or corrective actions that are not supported by the published project evidence. Where operational details are confidential or were not captured for public release, the case study documents the design boundary and lesson instead of presenting an unsupported narrative.

Security, Compliance and Risk

The public record avoids secrets, customer data, and private infrastructure details. The relevant security controls, access boundaries, and operational risks are addressed in the implementation notes where they are material to the project.

Testing, Validation and Evidence

The evidence published for this project is the documented implementation, its stated architecture and controls, and the portfolio record. 100% of analytics data stored within GCP. Cross-platform funnel analysis revealed mobile users convert to paid 2.3× faster than web users. Self-hosting cost: ~$45/month vs. PostHog Cloud equivalent at ~$450/month. Claims are limited to the implementation details and outcomes documented in this case study.

Results and Evidence

100% of analytics data stored within GCP. Cross-platform funnel analysis revealed mobile users convert to paid 2.3× faster than web users. Self-hosting cost: ~$45/month vs. PostHog Cloud equivalent at ~$450/month.

What I Learned

This project reinforced that product intelligence work is not a technology checklist. The durable value comes from making boundaries, trade-offs, ownership, and evidence clear enough for another engineer or stakeholder to review and operate the system responsibly.

What I Would Improve Next

• Expand automated validation around the most important workflow and control boundaries.
• Add or deepen operational evidence, such as dashboards, test artefacts, or an architecture diagram where it is safe to publish one.
• Review the design against the next expected scale, reliability, and governance requirement before extending the system.

Final Takeaway

This product development case study addresses a defined technical problem through PostHog, Compute Engine, Cloud SQL. It demonstrates my ability to turn requirements into an explainable design, implement the important controls, and document outcomes and limitations without overstating what the evidence proves.