As of May 2023, PostHog no longer support Kubernetes deployments. This decision doesn't impact open source ("Hobby") users on Docker Compose deployments.
To continue using PostHog, you have two options:
We strongly encourage users to move to PostHog Cloud wherever possible so that they always have the latest features and the full benefit of official support. It usually works out much cheaper, too.
PostHog Cloud is SOC 2 compliant and available with either EU or US hosting options. If you already have a self-hosted instance, you can migrate to PostHog Cloud. Alternatively, you can choose to migrate to a open source deployment instead.
If you want to continue using a self-hosted PostHog deployment then you do so without support.
We strongly recommend following the official instructions to deploy PostHog if you must self-host. Most people who modify or use a non-standard way of running this chart run into issues, which we are unable to help with.
Security updates will continue until May 2024.
🦔 PostHog is a developer-friendly, open-source product analytics suite.
This Helm chart bootstraps a PostHog installation on a Kubernetes cluster using the Helm package manager.
- Kubernetes >=1.24 <= 1.26
- Helm >= 3.7.0
Deployment instructions for the major cloud service providers and on-premise deploys are available here.
We documented detailed changes for each major release in our upgrade notes.
We welcome all contributions to the community, but no longer offer any support.
This repo uses several types of test suite targeting different goals:
- lint tests: to verify if the Helm templates can be rendered without errors
- unit tests: to verify if the rendered Helm templates are as we expect
- integration tests: to verify if applying the rendered Helm templates against a Kubernetes target cluster gives us the stack and PostHog installation we expect
We use helm lint that can be invoked via: helm lint --strict --set "cloud=local" charts/posthog
In order to run the test suite, you need to install the helm-unittest plugin. You can do that by running: helm plugin install https://github.com/quintush/helm-unittest --version 0.2.8
For more information about how it works and how to write test cases, please look at the upstream documentation or to the tests already available in this repo.
To run the test suite you can execute: helm unittest --helm3 --strict --file 'tests/*.yaml' --file 'tests/clickhouse-operator/*.yaml' charts/posthog
If you need to update the snapshots, execute:
helm unittest --helm3 --strict --file 'tests/*.yaml' --file 'tests/**/*.yaml' charts/posthog -u
- kubetest: to verify if applying the rendered Helm templates against a Kubernetes target cluster gives us the stack we expect (example: are the disks encrypted? Can this pod communicate with this service?)
- k6: HTTP test used to verify the reliability, performance and compliance of the PostHog installation (example: is the PostHog ingestion working correctly?)
- e2e - k3s: to verify Helm install/upgrade commands on a local k3s cluster
- e2e - Amazon Web Services, e2e - DigitalOcean, e2e - Google Cloud Platform: to verify Helm install command on the officially supported cloud platforms
k6 test is using k3s for running things on localhost, which might be tricky to get running locally. Here's one method:
# Install k3s without system daemon
curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_ENABLE=true sh
# Once done run k3s manually, disabling conflicting services
sudo k3s server --write-kubeconfig-mode 644 --disable traefik --docker --disable-network-policy
# Deploy the chart
helm upgrade --install -f ci/values/k3s.yaml --timeout 20m --create-namespace --namespace posthog posthog ./charts/posthog --wait --wait-for-jobs --debug
# Once done, prepare the data/environment
./ci/setup_ingestion_test.sh
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
export POSTHOG_API_ADDRESS=$(kubectl get svc -n posthog posthog-web -o jsonpath="{.spec.clusterIP}")
export POSTHOG_EVENTS_ADDRESS=$(kubectl get svc -n posthog posthog-events -o jsonpath="{.spec.clusterIP}")
export "POSTHOG_API_ENDPOINT=http://${POSTHOG_API_ADDRESS}:8000"
export "POSTHOG_EVENT_ENDPOINT=http://${POSTHOG_EVENTS_ADDRESS}:8000"
export "SKIP_SOURCE_IP_ADDRESS_CHECK=true"
# Run test
k6 run ci/k6/ingestion-test.jsTo release a new chart, bump the version in charts/posthog/Chart.yaml. We use Semantic Versioning:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner
PATCH version when you make backwards compatible bug fixes
Read API here as the chart values interface. When increasing the MAJOR version, ensure to add appropriate documentation to the Upgrade notes.
Charts are published on push
to the main branch.
Note that development charts are also released on PRs such that changes can be tested as required before merge, e.g. changing staging/dev to use the chart for more end to end validation.