plausible/analytics: the Dockerfile defaults to building the community edition

MIX_ENV=ce is the default, so the image you build is the community edition

The Dockerfile sets its build environment from an argument, and the default is not the hosted product.

ARG MIX_ENV=ce
ENV MIX_ENV=$MIX_ENV
ENV NODE_OPTIONS=--openssl-legacy-provider

The dependency fetch, mix deps.get --only ${MIX_ENV}, is scoped by that value. So a build with no arguments produces the Community Edition, which is the edition the project describes as free as in beer and the one where you own the server. The hosted cloud service is a separate product on a separate release rhythm, described as receiving updates multiple times per week. The consequence for anyone building from source is that a default build produces the Community Edition. Read the edition comparison before you assume you have installed the same thing.

Local ClickHouse tracks latest-alpine while a separate target pins production

The Makefile offers two ways to get the event database, and the difference between them is the version tag. The development target starts a recent image using the latest-alpine tag, while the production target is described as starting a container with the same version of clickhouse as the one in prod, and it pins an exact build. The two also use different volume paths, one for development data and one for production data, so they do not share state. The consequence is a version gap that moves without you: a development environment started last month is not running the same ClickHouse as your production one, and a query or a migration that behaves differently between the two is a version difference before it is a bug. The pinned target exists precisely to remove that variable, so use it when you are reproducing something that happened upstream, and do not assume the floating tag is equivalent.

The development database runs on host networking with user setup skipped

The shared flags used to start the container are worth reading in full.

CH_FLAGS ?= --detach -p 8123:8123 -p 9000:9000 --ulimit nofile=262144:262144 --name plausible_clickhouse --env CLICKHOUSE_SKIP_USER_SETUP=1

Two of those values matter outside the developer machine. The network mode for the development target is host, so the ports are bound to the host rather than to an isolated bridge, and the skip user setup environment variable turns off the database's own account provisioning. Together they mean that on a laptop, the event database is reachable by anything that can reach that host on those two ports, with no credential step in the way. This is a development convenience and it is a poor configuration for a shared machine, a laptop tethered to a corporate network, or any host you do not exclusively control. The container is also named, and the client target connects by that name, which is why a stale container with the same name will collide with a fresh one.

make install runs two npm subprojects alongside ecto and a country database

The initial setup target is a chain of seven commands, and the order matters.

mix deps.get
mix ecto.create
mix ecto.migrate
mix download_country_database
npm install --prefix assets
npm install --prefix tracker
npm run deploy --prefix tracker

The first four are Elixir. Creating and migrating the schema implies a PostgreSQL instance you already have, and downloading the country database is a separate network fetch that populates the geolocation data behind country level reports, so a fresh install touches the network for data as well as for packages. The last three are Node, applied to two separate npm subprojects, assets and tracker, each with its own package.json and lockfile. So the Elixir application is not self-contained at build time: it carries two JavaScript build trees and two more lockfiles that have to stay consistent with mix.lock. That is the real shape of a from-source setup.

Node is copied in from a second image because apk cannot pin it

The build solves a packaging problem in a way worth knowing about. A comment at the top explains that a pre-built tar cannot be used because the distribution is platform specific, so the build happens inside the image. Then a comment on the Node step says apk can not pin a nodejs version reliably, so rather than installing Node from Alpine packages, the binary and npm are copied out of a separate node image into the Elixir builder. Both base images are pinned by digest, so the Node version is reproducible even though it was obtained by copying a file across image boundaries. The environment also sets NODE_OPTIONS to a legacy OpenSSL provider flag for the asset build, which is a signal that the frontend build still depends on a legacy crypto path that a current Node would otherwise refuse. None of this affects a user of the hosted service, and all of it affects anyone trying to reproduce or patch the build.

The newest tag is four months behind the last commit on master

The three most recent releases are v3.2.0-rc.0 from December 2025, v3.2.0 from January 2026, and v3.2.1 from 15 May 2026. The most recent push to the repository is dated 2 November 2026. That is more than five months of work without a new tag. For a self-hoster this is a real fork in the road rather than a technicality. The tagged release is a known, reproducible point, and the branch tip is newer and untagged. The hosted service does not have this problem, since the project describes it as continuously developed with updates multiple times per week, which is the clearest statement in the repository of how the two editions diverge over time. Decide which side of that gap you are installing before you start, and record the commit you installed.

AGPL-3.0 for the code, a subscription for the service, and a list you inherit

The repository is licensed AGPL-3.0 and the hosted service is a paid subscription, and the project is direct about the reason: it charges to fund development because it does not monetize user data the way advertising funded analytics does. The self-hosted Community Edition is the free one, and the project's own comparison table enumerates exactly what you take on. You need a server, and you are responsible for installation, maintenance, upgrades, server capacity, uptime, backup, security, stability, consistency and loading time. That is not a hedge, it is the itemised handover of operational ownership. The license point is separate and easy to miss: if you modify and redistribute the self-hosted build, the AGPL terms are the ones that apply to what you hand on, so read LICENSE.md before you fork it internally and publish anything.

Cookie-free is a data model, and it bounds the questions you can answer

The privacy claim is specific, and it is worth reading as a constraint on measurement rather than as a feature. The project states that no personal data or IP addresses are stored, that no cookies or persistent identifiers are used, and that the intent is to measure traffic rather than individuals. Everything else follows from that. Goals, conversions, revenue attribution and funnels are built on custom events and dimensions. Codeless tracking covers outbound link clicks, form completions, file downloads and 404 pages, which is page level rather than person level. Single page applications are handled out of the box including pushState and hash based routing, so client side navigation is counted. What you do not get is a durable notion of an individual visitor, so retention over time, per user funnels and anything requiring identity across sessions are outside what this data model holds. If your reporting depends on those, no amount of configuration recovers them.

Editorial conclusion

Use the cloud service if you want correct numbers and no operational work, since the project states it is continuously updated multiple times per week. Use the Community Edition if you need to own the data path and you already have someone who will own a server, a ClickHouse container and the upgrade cadence. Do not expect the self-hosted build to match the hosted product's release rhythm. Before choosing, check four things yourself: the privacy posture actually fits your consent model, the two data stores on your infrastructure are ones you can back up, the version gap between the newest tag and the default branch does not strand you, and the reporting features you need exist in the edition you are installing.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes