⚠️ Follow these instructions instead of modifying or running this chart
If you make changes to these helm charts, however simple, we won't be able to support you. Most people who modify or use a non-standard way of running this chart run into issues. We strongly recommend following the official instructions to deploy PostHog.
If there are changes you need, please raise a PR or reach out on Slack so we can help you.
🦔 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.23 <= 1.25
- Helm >= 3.7.0
Deployment instructions for the major cloud service providers and on-premise deploys are available here.
We document detailed changes for each major release in the upgrade notes.
The main purpose of this repository is to continue evolving our Helm chart, making it faster and easier to use. We welcome all contributions to the community and are excited to welcome you aboard.
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.js
To 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.