Self-Hosting PostHog on Linux VPS in Pakistan: Open-Source Product Analytics & Session Replay Guide

Building modern digital products requires granular behavioral telemetry: funnel drop-off analysis, feature flag rollouts, user path cohorting, and session recordings that reveal real-world UI friction. For Pakistani software houses, digital agencies, fintech platforms, and SaaS startups, product analytics traditionally meant subscribing to US-based multi-tenant platforms such as Mixpanel, Amplitude, and Hotjar.

However, compounding macroeconomic pressures and regulatory compliance mandates have turned foreign event-metered SaaS tools into unsustainable cost centers. Self-hosting PostHog on a dedicated Linux VPS provides product teams with total data ownership, sub-second ClickHouse query performance, unthrottled session replays, and predictable local infrastructure budgeting.

This technical guide covers the end-to-end architecture, production Docker Compose orchestration, ClickHouse memory tuning, Nginx WebSocket reverse proxy configuration, frontend SDK masking, and storage lifecycle management required to run PostHog at scale in Pakistan.

---

The Macroeconomic and Compliance Case for Self-Hosting

Pakistani tech companies operate under unique fiscal and regulatory constraints that make conventional foreign SaaS analytics platforms problematic.

Rupee Depreciation and Foreign Exchange Restrictions

Foreign analytics providers charge on metered consumption models based on monthly tracked users (MTUs) or total event volume. A consumer mobile application or B2B SaaS handling 15 million monthly user events routinely incurs monthly bills ranging from $800 to $3,500 USD.

Under continuous currency volatility, budgeting foreign SaaS expenses introduces severe forecasting risk. Furthermore, the State Bank of Pakistan (SBP) enforces stringent foreign exchange limits on corporate debit and credit cards, often capping single-transaction or monthly international software payments. Software teams frequently encounter declined transactions, service suspensions, or arbitrary merchant blocks.

Advance Tax on Foreign Digital Transactions

Under Pakistan’s Federal Board of Revenue (FBR) tax regime, payments made to non-resident entities via corporate credit cards attract advance withholding taxes under Section 236Y of the Income Tax Ordinance. Depending on whether an organization is on the Active Taxpayers List (ATL) or non-ATL, this surcharges foreign SaaS invoices by 5% to 10% in upfront non-recoverable withholding costs, substantially inflating the true cost of offshore analytics.

Data Sovereignty and Sensitive Session Replays

Modern product analytics extends beyond anonymous pageviews; it captures user identity graphs, clickstreams, and complete screen recordings. For Pakistani financial applications, micro-lending apps, telemedicine portals, and e-commerce platforms, streaming end-user sessions to multi-tenant servers hosted in overseas jurisdictions introduces severe compliance liabilities under domestic data protection standards and banking security regulations.

Self-hosting PostHog ensures all telemetry, personally identifiable information (PII), and session captures remain isolated within your private network perimeter.

---

Architectural Breakdown of Self-Hosted PostHog

PostHog is an enterprise-grade distributed system designed to ingest, process, and query billions of events. Unlike basic web analytics platforms that rely on standard relational databases, PostHog leverages an advanced hybrid architecture:

[ Web / Mobile Clients ]
         │ (HTTPS / WebSockets)
         ▼
[ Nginx Reverse Proxy (SSL Termination) ]
         │
         ├──► /e/ (Event Capture API - Node.js)
         │           │
         │           ▼
         │   [ Kafka / Redis Ingestion Buffer ]
         │           │
         │           ▼
         │   [ Ingestion Workers / Plugin Server ]
         │           │
         │           ▼
         │   [ ClickHouse Columnar OLAP Database ]
         │
         └──► /api/ & UI (Django Application Server)
                     │
                     ├──► [ PostgreSQL 16 (Metadata & Auth) ]
                     ├──► [ Redis (Session Cache & Worker Queue) ]
                     └──► [ Celery / Temporal Async Workers ]

Component Breakdown

1. ClickHouse Columnar OLAP Database: ClickHouse serves as the analytical backbone. Because data is stored in columns rather than rows, aggregation queries (such as calculating the 7-day conversion rate across a 5-step funnel over 50 million events) scan only the required columns from disk. Combined with LZ4 and ZSTD compression algorithms, ClickHouse executes complex queries in hundreds of milliseconds where traditional PostgreSQL or MySQL databases would lock and time out.

2. Ingestion Queue Backplane (Kafka and Redis): When client browsers and mobile apps dispatch event payloads, the high-throughput Node.js capture endpoint writes events directly into an asynchronous queue (Apache Kafka or Redis streams). This architectural buffer decouples event ingestion from disk storage, ensuring your application never drops telemetry during traffic spikes.

3. PostgreSQL 16 Metadata Store: PostgreSQL handles relational, ACID-compliant application data. It stores organizational workspaces, team permissions, dashboard layouts, feature flag definitions, saved insights, and identity mapping tables.

4. Django API and Worker Layer: PostHog’s web application and REST API run on Python/Django. Background tasks, including scheduled email digests, identity merging, asynchronous exports, and cohort calculations, are orchestrated via Celery and background worker queues.

---

Hardware Sizing and Infrastructure Prerequisites

PostHog’s multi-container topology requires adequate CPU, memory, and high-performance storage. Running PostHog on under-provisioned infrastructure will lead to ClickHouse memory exhaustion and ingestion backpressure.

Monthly Ingestion Volume	Recommended Configuration	Storage Specification	Deployment Tier
Up to 1,000,000 events	4 vCPU / 8 GB RAM	80 GB Pure NVMe	Staging / Growth MVP
1,000,000 to 10,000,000 events	8 vCPU / 16 GB to 32 GB RAM	250 GB PCIe Gen4 NVMe	Production Linux VPS
10,000,000+ events	16+ Cores / 64 GB+ ECC RAM	Pure NVMe RAID 10 Array	Dedicated Servers

Linux Kernel Pre-Flight Tuning

Before deploying the container runtime on Ubuntu 24.04 or 22.04 LTS, tune kernel memory allocation limits and file descriptor ceilings to support ClickHouse and Kafka workloads:

# Append production sysctl parameters
cat <<EOF | sudo tee /etc/sysctl.d/99-posthog.conf
vm.max_map_count=262144
fs.file-max=2097152
net.core.somaxconn=4096
vm.overcommit_memory=1
EOF

# Apply kernel settings without reboot
sudo sysctl --system

# Set persistent resource limits
cat <<EOF | sudo tee /etc/security/limits.d/99-posthog.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 32768
* hard nproc 32768
EOF

---

Production Docker Compose Orchestration

The following production-ready Docker Compose configuration deploys PostHog services with persistent data volumes, healthy dependency checks, and internal service network isolation.

Create a dedicated directory and environment configuration:

sudo mkdir -p /opt/posthog && cd /opt/posthog
sudo chown -R $USER:$USER /opt/posthog

Environment Variable Secrets File (.env)

Generate cryptographically secure passwords for each database service:

cat <<EOF > .env
POSTHOG_SECRET=$(openssl rand -hex 32)
POSTGRES_PASSWORD=$(openssl rand -hex 24)
CLICKHOUSE_PASSWORD=$(openssl rand -hex 24)
REDIS_PASSWORD=$(openssl rand -hex 24)
DOMAIN=analytics.yourcompany.pk
SITE_URL=https://analytics.yourcompany.pk
EOF

Docker Compose Configuration (docker-compose.yml)

version: '3.8'

networks:
  posthog-internal:
    driver: bridge

volumes:
  postgres-data:
  clickhouse-data:
  redis-data:

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: posthog
      POSTGRES_USER: posthog
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - posthog-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U posthog"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}"]
    volumes:
      - redis-data:/data
    networks:
      - posthog-internal
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  clickhouse:
    image: clickhouse/clickhouse-server:24.3
    restart: unless-stopped
    environment:
      CLICKHOUSE_DB: posthog
      CLICKHOUSE_USER: default
      CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD}
    volumes:
      - clickhouse-data:/var/lib/clickhouse
      - ./clickhouse-config.xml:/etc/clickhouse-server/config.d/custom-config.xml:ro
      - ./clickhouse-users.xml:/etc/clickhouse-server/users.d/custom-users.xml:ro
    networks:
      - posthog-internal
    ulimits:
      nofile:
        soft: 262144
        hard: 262144

  web:
    image: posthog/posthog:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      SECRET_KEY: ${POSTHOG_SECRET}
      DATABASE_URL: postgres://posthog:${POSTGRES_PASSWORD}@postgres:5432/posthog
      CLICKHOUSE_HOST: clickhouse
      CLICKHOUSE_USER: default
      CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD}
      REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/
      SITE_URL: ${SITE_URL}
      PRIMARY_COMMERCIAL_LINK: /servers/vps-pk
    ports:
      - "127.0.0.1:8000:8000"
    networks:
      - posthog-internal

  worker:
    image: posthog/posthog:latest
    restart: unless-stopped
    command: ["./bin/docker-worker"]
    depends_on:
      - web
    environment:
      SECRET_KEY: ${POSTHOG_SECRET}
      DATABASE_URL: postgres://posthog:${POSTGRES_PASSWORD}@postgres:5432/posthog
      CLICKHOUSE_HOST: clickhouse
      CLICKHOUSE_USER: default
      CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD}
      REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/
      SITE_URL: ${SITE_URL}
    networks:
      - posthog-internal

---

ClickHouse Memory Tuning and OOM Prevention

The single most common cause of self-hosted PostHog instability is the Linux Out-Of-Memory (OOM) killer terminating the ClickHouse process during heavy analytical scans.

When computing funnels across several million events with property breakdown criteria, ClickHouse constructs large in-memory state hash tables. Without explicit memory ceilings, ClickHouse attempts to satisfy the query by allocating all remaining host RAM, triggering an immediate kernel OOM kill.

ClickHouse System Sizing (clickhouse-config.xml)

Create an XML override that caps ClickHouse server allocation at 70% of total host RAM:

<!-- /opt/posthog/clickhouse-config.xml -->
<clickhouse>
    <max_server_memory_usage_to_ram_ratio>0.7</max_server_memory_usage_to_ram_ratio>
    <mark_cache_size>2147483648</mark_cache_size>
    <uncompressed_cache_size>1073741824</uncompressed_cache_size>
</clickhouse>

ClickHouse Query Execution Ceilings (clickhouse-users.xml)

Enforce strict limits on single-query consumption to protect the instance from unconstrained analytical queries:

<!-- /opt/posthog/clickhouse-users.xml -->
<clickhouse>
    <profiles>
        <default>
            <!-- 10 GB maximum RAM per query execution -->
            <max_memory_usage>10000000000</max_memory_usage>
            <max_memory_usage_for_user>12000000000</max_memory_usage_for_user>
            <max_execution_time>60</max_execution_time>
            <log_queries>1</log_queries>
            <joined_subquery_requires_alias>0</joined_subquery_requires_alias>
        </default>
    </profiles>
</clickhouse>

With max_server_memory_usage_to_ram_ratio = 0.7 and max_memory_usage = 10000000000, a query that exceeds 10 GB will gracefully abort with an informative error in the PostHog UI instead of crashing the database container.

---

Nginx Reverse Proxy with WebSocket Support

PostHog’s real-time features (live event feeds, session replay streaming, and feature flag evaluations) require persistent HTTP/2 and WebSocket connections.

Install Nginx and Certbot:

sudo apt update && sudo apt install -y nginx certbot python3-certbot-nginx

Configure the virtual host at /etc/nginx/sites-available/posthog:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name analytics.yourcompany.pk;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name analytics.yourcompany.pk;

    ssl_certificate /etc/letsencrypt/live/analytics.yourcompany.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/analytics.yourcompany.pk/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # Payload limits for session recording blobs
    client_max_body_size 50M;

    # Proxy buffers for high-volume event ingestion
    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;

        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Standard client identity forwarding
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts for streaming session recordings
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

Enable the site and obtain the TLS certificate:

sudo ln -s /etc/nginx/sites-available/posthog /etc/nginx/sites-enabled/
sudo certbot --nginx -d analytics.yourcompany.pk
sudo nginx -t && sudo systemctl reload nginx

---

Frontend SDK Integration and PII Masking

Capturing product telemetry without data sanitization creates critical security liabilities. PostHog session replays record the DOM tree and user interactions. If left unmasked, passwords, National Identity Card (CNIC) numbers, IBANs, and credit card details could be recorded into ClickHouse.

Next.js (App Router) Implementation

Install the client SDK:

npm install posthog-js

Initialize PostHog in a dedicated client provider (app/providers.tsx):

'use client';

import posthog from 'posthog-js';
import { PostHogProvider as PHProvider } from 'posthog-js/react';
import { useEffect } from 'react';

export function PostHogProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    posthog.init('YOUR_PROJECT_API_KEY', {
      api_host: 'https://analytics.yourcompany.pk',
      ui_host: 'https://analytics.yourcompany.pk',
      person_profiles: 'identified_only',
      capture_pageview: true,
      capture_pageleave: true,
      session_recording: {
        maskAllInputs: true,
        maskTextSelector: '.sensitive-data, [data-ph-mask]',
        maskInputOptions: {
          password: true,
          email: false,
          tel: true,
        },
      },
    });
  }, []);

  return <PHProvider client={posthog}>{children}</PHProvider>;
}

HTML Attribute Masking Pattern

In JSX or raw HTML, mark any element containing financial or customer identity data with the data-ph-mask attribute:

<!-- Sensitive Pakistani customer attributes are obscured in replays -->
<div class="user-billing-card" data-ph-mask>
  <p>Account Holder: Muhammad Ali</p>
  <p>CNIC: 35201-XXXXXXX-X</p>
  <p>Bank Al-Habib IBAN: PK36BAHL0000000000000000</p>
</div>

<!-- Form inputs with automated masking -->
<input 
  type="text" 
  name="jazzcash_mobile_account" 
  data-ph-mask 
  placeholder="03XXXXXXXXX" 
/>

When PostHog’s recording engine processes elements matching data-ph-mask, the text content and input values are replaced with asterisks before transmission over the network.

Flutter Mobile SDK Implementation

For Pakistani cross-platform mobile apps built with Flutter, integrate posthog_flutter:

import 'package:posthog_flutter/posthog_flutter.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await Posthog().setup(
    PosthogConfig('YOUR_PROJECT_API_KEY')
      ..host = 'https://analytics.yourcompany.pk'
      ..sessionReplay = false // Disable or strictly configure on mobile
      ..captureApplicationLifecycleEvents = true,
  );

  runApp(const MyApp());
}

// Tracking critical e-commerce or SaaS conversions
void trackOrderCompleted(String orderId, double amountPkr) {
  Posthog().capture(
    eventName: 'order_completed',
    properties: {
      'order_id': orderId,
      'amount_pkr': amountPkr,
      'payment_method': 'EasyPaisa',
      'currency': 'PKR',
    },
  );
}

---

ClickHouse Partitioning, Retention Policies, and Disk Compaction

Unchecked event storage will eventually saturate local NVMe drives. Establishing automated data lifecycle policies ensures predictable disk consumption.

Automated Time-to-Live (TTL) Policy

Connect to ClickHouse via the command-line interface:

docker compose exec clickhouse clickhouse-client --user default --password "${CLICKHOUSE_PASSWORD}" --database posthog

Configure a 90-day retention window on raw event and session replay tables:

-- Enforce automated 90-day partition eviction
ALTER TABLE events MODIFY TTL toDate(timestamp) + INTERVAL 90 DAY;

-- Verify table TTL configuration
SHOW CREATE TABLE events;

Monthly Partitioning Strategy

ClickHouse automatically organizes tables into partitions according to your partition key (e.g., PARTITION BY toYYYYMM(timestamp)). This structure allows the database engine to drop or detach entire calendar months without triggering row-level deletion overhead:

-- View partition disk utilization
SELECT 
    partition,
    formatReadableSize(sum(bytes_on_disk)) AS disk_size,
    sum(rows) AS total_rows
FROM system.parts
WHERE table = 'events' AND active = 1
GROUP BY partition
ORDER BY partition DESC;

-- Instantly purge an old calendar month if storage thresholds are reached
ALTER TABLE events DROP PARTITION '202511';

Routine Disk Compaction

ClickHouse continuously merges data parts in the background. To reclaim disk space following major deletions or bulk imports, execute an explicit compaction routine during off-peak hours:

#!/bin/bash
# /opt/posthog/scripts/compact-clickhouse.sh
docker compose exec -T clickhouse clickhouse-client \
  --user default \
  --password "${CLICKHOUSE_PASSWORD}" \
  --database posthog \
  --query "OPTIMIZE TABLE events FINAL;"

Schedule this script via cron to run weekly during low-traffic windows.

---

Hardware Scaling Boundaries: From Linux VPS to Bare-Metal Infrastructure

A properly tuned Linux VPS handles millions of monthly events reliably. However, as your product scales, virtualization imposes technical constraints that necessitate physical hardware upgrades.

When to Upgrade from VPS to Dedicated Servers

Evaluate these three operational thresholds to determine when shared hypervisor virtualization must yield to dedicated compute:

1. Ingestion Volume Exceeds 10,000,000 Monthly Events: At high event velocities, write amplification across Kafka, Redis, and ClickHouse creates continuous disk I/O demands. Shared hypervisors enforce I/O throttling, causing ingestion queues to accumulate backpressure.
2. Multi-Stage Cohort Analysis Latency: When product managers run complex multi-touch attribution queries or year-long retention cohorts across hundreds of gigabytes of telemetry, memory bus contention on virtualized platforms leads to query timeouts.
3. Session Replay Video Storage Throughput: High-definition DOM session recordings generate substantial sustained write throughput. Pure hardware RAID configurations prevent storage write saturation.

When your application crosses these volume thresholds, migrating PostHog to bare-metal Dedicated Servers or localized Dedicated Servers in Pakistan delivers dedicated CPU execution units, direct PCIe bus access, unthrottled NVMe read/write operations, and predictable sub-second query performance.

---

Architectural Comparison: Self-Hosted PostHog vs. Proprietary SaaS

Operational Dimension	Self-Hosted PostHog on Nextgen VPS	Proprietary SaaS (Mixpanel / Amplitude / Hotjar)
Billing Currency	Predictable local PKR invoices	Variable USD consumption billing subject to FX rate swings
Withholding Tax	Standard local corporate billing (FBR compliant)	5%–10% advance withholding tax under Section 236Y
Payment Constraints	Local bank transfer, PayFast, 1LINK	SBP commercial card limits, frequent bank transaction blocks
Data Residency	100% private infrastructure, complete audit control	Multi-tenant offshore cloud datacenters (US/EU)
Session Replay Limits	Unlimited storage governed only by your disk size	Expensive tiered pricing per 1,000 recorded sessions
Query Engine	Bare-metal ClickHouse OLAP with direct SQL access	Black-box proprietary analytical engine with export fees

---

Conclusion

Self-hosting PostHog on a high-performance Linux VPS allows Pakistani software engineering and product teams to break free from aggressive USD SaaS pricing, FX transaction limits, and data sovereignty liabilities.

With ClickHouse’s columnar OLAP performance, Nginx WebSocket proxying, and frontend PII sanitization, you retain complete control over your product data while keeping your infrastructure investment predictable, localized, and compliant.