Plausible Community Edition is the analytics server you host. Tracksible does not install beside it. Tracksible is an independent companion by Webjuice. It is not affiliated with, endorsed by, or supported by Plausible Insights OÜ.
This guide follows the current Community Edition repository and its linked wiki. It covers the server first. The phone app comes only after that server is running and recording visits.
Community Edition is not Plausible Cloud
Plausible Analytics offers two ways to run the same open-source analytics code. Plausible Cloud is the managed service. Plausible Community Edition, or CE, is the free AGPL-licensed release that you operate on your own infrastructure.
That difference is operational, not just a different checkout page. With Cloud, Plausible manages the hosting, high availability, backups, security, maintenance and capacity. With CE, those jobs become yours. You choose and pay for the server. You monitor uptime and dashboard performance. You maintain TLS, apply security releases, test upgrades and keep restorable backups.
The release schedules also differ. The official Cloud and CE comparison describes Cloud as continuously updated. CE uses longer-term releases published less often. A feature that exists in Cloud may therefore be absent from the CE release you run, even before the documented product differences are considered.
CE does not include several Cloud-only features listed on that page: marketing funnels, user journeys, ecommerce revenue goals, SSO and the sites API. Its bot filtering is also more limited. Cloud adds filtering for non-human traffic patterns and data-centre address ranges, while CE uses basic filtering based on user agents and referrer-spam domains.
Support is different too. A Cloud subscription includes support from the Plausible team. CE is community supported. Control is the benefit, but responsibility is the price. If your backup has not been tested, your certificate expires or your server runs out of capacity, there is no managed service absorbing the incident for you.
Choose CE because you want to run the infrastructure and accept that work. Do not choose it on the assumption that it is Plausible Cloud without a subscription.
What you need before you install
The live Community Edition repository lists three machine requirements. Docker and Docker Compose must be installed. The CPU must support SSE 4.2 or NEON because ClickHouse requires one of those instruction sets. At least 2 GB of RAM is recommended for running Plausible and ClickHouse without out-of-memory failures.
Treat 2 GB as the repository’s floor for those services, not a promise for every workload. Your traffic, retention and other processes on the same machine consume capacity too. Monitor the machine after launch instead of assuming the minimum will remain enough.
You also need a DNS name for the analytics instance. Use a dedicated host such as plausible.example.com. The official quick start expects BASE_URL to be the real domain where CE will answer. That name must resolve to the server before automatic certificate issuance can work.
Use a subdomain, not a subfolder such as example.com/analytics. A separate host keeps the public URL, certificate, reverse proxy and generated links aligned with the application’s expected base address.
Decide who owns routine operations before installing. Someone needs access to the server, DNS, backup system and repository clone. That person also needs a maintenance window for upgrades and a way to confirm that both databases can be restored.
Install with the official Compose repo
The repository is the installation authority. As reviewed on 15 September 2026, its quick start pins the clone to branch v3.2.1. Use the branch shown in the live README when you install, rather than copying an old command from a third-party article.
- Clone the documented branch into a dedicated directory, then enter it.
git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ceThe checkout contains the maintained compose.yml and ClickHouse configuration. Keep your local changes out of that tracked Compose file. The project’s compose override guide exists so local ports, volumes or environment settings can live in compose.override.yml without creating merge conflicts during updates.
- Create
.envand set the public address and application secret.
touch .env
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .envReplace the example host with the DNS name you control. Keep the secret out of screenshots, tickets and copied terminal output. The README says SECRET_KEY_BASE must be at least a 64-byte string; its documented OpenSSL command generates the value for the quick start.
For a local evaluation only, the README allows an HTTP address such as http://localhost:8000. A public deployment should use the real HTTPS address from the start so generated URLs and browser requests agree.
- Choose how the service reaches the web. For the repository’s built-in certificate path, add the documented port variables to
.env.
echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .envThen expose those ports in compose.override.yml as the README shows:
services:
plausible:
ports:
- 80:80
- 443:443If another proxy already owns ports 80 and 443, do not use that public-port example unchanged. Follow the reverse-proxy route in the next section and choose the local binding that fits your host.
- Start the services.
docker compose up -dCompose starts the services defined by the official repository. Do not add unrelated databases or replace the maintained topology during the initial install. Let the documented configuration establish a known baseline first.
- Visit the exact address in
BASE_URLand create the first user. If the page does not load, stop here. Check DNS, container health and the public path before adding a site or connecting another client.
TLS and reverse proxies
The current quick start can obtain a Let’s Encrypt certificate when its HTTP and HTTPS ports are exposed as documented. DNS must already point the instance name at the server. Ports 80 and 443 must reach the Plausible service for that path to work.
If a load balancer, hosting panel, Caddy, Nginx or Apache terminates TLS, use the official reverse-proxy guide. It explains how to expose CE on an internal HTTP port and keep BASE_URL equal to the public HTTPS domain. The wiki notes that its Nginx and Apache examples are community contributions and were not tested by the maintainers, so review them against the proxy you actually run.
Do not stack both certificate paths accidentally. Decide whether CE or the outer proxy owns HTTPS. Then expose only the ports required by that design and confirm that the public domain still matches BASE_URL.
Coolify already has its own proxy and resource flow. Follow Install Plausible Analytics on Coolify instead of translating the manual port steps into guessed panel settings.
Script, first site, and a working check
A healthy login page proves the application answers. It does not prove that your website is sending events.
Sign in to CE and add the first site. Use the same site domain that visitors will load. Plausible displays a site-specific tracking snippet during setup. For an existing site, the current Plausible script guide says to open the site’s settings, find the Tracking area and review the site installation details.
Place the snippet in the page’s <head> using the instructions for your site builder or framework. Publish that change. Then open the public page in a normal browser and navigate once or twice.
Return to the CE dashboard and confirm that the test visit appears. If it does not, use Plausible’s installation check and integration troubleshooting before moving on. Verify the site domain, public script request and any content-security policy. A mobile viewer cannot repair a tracker that never sends a pageview.
Keep this check simple. One known page, one known visit and one dashboard result give you a baseline. Add goals, team access and other integrations only after basic collection is visible.
Upgrades, backups, and support
Self-hosting is ongoing work. The official comparison says security fixes protect a CE instance only after its operator applies the release. Watch the Plausible Analytics releases and read the notes for every version between the one you run and the one you plan to install.
The Community Edition Upgrade wiki page says each release can carry version-specific instructions. For minor updates, its general flow is to pull the target branch or version and run docker compose up -d. Major updates may require extra migrations. The release notes take precedence over that general outline.
The same upgrade page recommends pinning a patch version for control. It also warns that security patches and bug fixes are not backported. That combination means you need a deliberate update routine: know exactly which image or branch you run, subscribe to releases, review the migration notes, back up, then update.
Back up both persistent data stores: PostgreSQL and ClickHouse. PostgreSQL holds application records. ClickHouse holds analytics events. A copy of .env or compose.yml is not a data backup, and protecting only one database cannot restore a complete instance.
Keep the backups outside the server that runs CE. Protect the application secret and database credentials with the same care as the data. Define retention, monitor failed backup jobs and perform a restore test. A backup that has never been restored is an assumption, not a recovery plan.
Before an upgrade, record the running version and read the target release notes. Take a fresh backup of both stores. Preserve .env and compose.override.yml. After Compose recreates the containers, check their health, sign in, open a dashboard and send a test pageview. Do not call the maintenance complete just because the command exited without an error.
For advice, use the repository’s self-hosted support discussions. The wiki asks people requesting help to include the steps taken plus their Compose and environment configuration. Remove secrets before posting. Community support is not the premium support included with Plausible Cloud.
Other ways people host CE
These routes all lead to Community Edition. They differ in who prepares the Compose resource and who operates the surrounding host.
| Route | What to follow | Operational note |
|---|---|---|
| Official Docker Compose | This guide and the CE repository | Closest to the maintained quick start. You own the host, ports, TLS, backups and upgrades. |
| Coolify | The Coolify guide | Coolify documents a Compose paste, not a one-click service, because of its stated trademark restriction. |
| Any other Docker host | The same CE repository and wiki | Translate only the host’s networking and storage layer. Keep CE’s required services and current release instructions intact. |
Managed catalogues such as Elestio, PikaPods, Cloudron and similar services also exist on those vendors’ sites. Their plans, versions, backup policies and control-panel steps can change. Read the vendor’s current documentation rather than assuming its route matches the official Compose repository.
Coolify’s current instructions link a maintained Compose template. Do not treat that file as the general CE quick start. As reviewed, its Plausible image is v3.0.1, while the CE README clone branch is v3.2.1. Compare the live values when choosing a route because a panel template can lag the current CE repository.
Point Tracksible at the instance
Wait until CE answers on its public domain and a test pageview appears. Tracksible needs the instance address plus either a Stats API key or a share link. It does not install on the server, start Plausible, collect website events or provide hosting when you buy Pro.
Start with the self-hosted Tracksible page. The longer connection overview is Using a mobile app with self-hosted Plausible. If you are deciding which credential to use, read Plausible share link vs API key. The practical steps are under getting started.
Available metrics still depend on the server version, permissions, plan and connection type. Tracksible cannot display a metric the instance does not return.
Free covers one site. It includes Realtime, Today, Yesterday and Last 7 Days, with overview, audience, goals and insights. Widgets require Pro. Pro adds the paid features shown on pricing and is a one-time $9.99 in-app purchase, not Plausible hosting.
Install Tracksible on iPhone from the App Store or on Android from Google Play only after the server-side check passes. This keeps the two jobs separate: Community Edition records and serves the analytics; Tracksible provides a mobile view of the instance you already operate.
Sources
Reviewed 15 September 2026.
- Plausible Community Edition repository and README
- Plausible Community Edition wiki
- Compose override guide
- Reverse proxy guide
- Upgrade guide
- Plausible Cloud and Community Edition comparison
- Plausible tracking script guide
- Plausible Analytics releases
- Self-hosted support discussions
- Coolify Plausible service documentation
- Coolify Plausible Compose template