Self hosting Plausible

Simple and privacy-friendly alternative to Google Analytics

4 minutes

I only recently talked about using GoAccess as an analytics tool. Over the last couple months, I’ve been more interested in how many hits this website actually gets. GoAccess was a really simple solution which worked on log files and only captured the bits of information I really cared about: Page views.

After hearing about it on Changelog, I looked into Plausible. It’s much more powerful than GoAccess, and is actually designed for analytics. And because it’s working in the browser, I don’t have to ignore all the static paths to stop them showing up in the analytics.

#Why Plausible

Google Analytics is the current go-to solution for analytics, but it’s a non-starter for me due to privacy concerns. The fewer sites collecting information for Google, the better! Plausible positions itself directly as a GDPR-compliant, privacy-driven analytics platform.

Plausible is pretty new to the scene, But what it’s achieved in that time is quite remarkable. There’s now a functional, simple analytics platform, which collects only the data needed, and isn’t tied to a huge company like Google.

Plausible vs Google Analytics

Plausible’s primary offering is a hosted version, but in the last few weeks the option to self-host has been available. The hosted option is rock-solid, running on renewable energy, and definitely recommended if you don’t want to faff for yourself. Using the hosted version also financially supports the project, and ensures it stays around.



I wrote this installation guide a long time ago. As a result, many of the steps may be incorrect. If you’re after more up-to-date setup instructions, check out the official documentation.


The current options are to compile and run the Elixir application yourself, or use Docker. My servers already run Docker, so that was a simple decision! In the Plausible repository, there’s a docker-compose.yml - Don’t use it. It’s intended more as a reference to what’s needed for setup rather than to be used directly. However, from this we can see we need a couple containers:


A cautionary tale for installing Clickhouse. I’d intended to run it on a reasonably old machine (Intel Atom N2800), and due to a requirement on a specific instruction set (SSE4), it wouldn’t start. Chances are this won’t affect you if you’re running a server even remotely modern, but something to note.


#Setup and configuration

Fortunately, configuring Plausible is actually really simple and the settings are pretty obvious. There’s official hosting docs too, which should definitely be read. Here’s what I have set up for Plausible:

  - SECRET_KEY_BASE={{ secret_key }}
  - SIGNING_SALT={{ signing_salt }}
  - DATABASE_URL=postgres://plausible:plausible@db:5432/plausible
  - HOST={{ plausible_host }}
  - SCHEME=https

Some of these configuration options may have changed slightly since the time of writing. Take a look at the configuration options for the most up-to-date options.


$DISABLE_REGISTRATION and $DISABLE_SUBSCRIPTION are both pretty handy. These prevent other users from signing up to your instance, and stop showing anything to do with subscriptions. For now, the self-hosted Plausible comes with a 100-year subscription for admin users, which is very gracious.

$SECRET_KEY_BASE and $SIGNING_SALT should be kept private at all costs. There’s little documentation on what these should be or how to generate them, but according to Phoenix $SECRET_KEY_BASE should be at least 64 bytes. $SIGNING_SALT just needs to be something reasonably complex, but I used 16 bytes for ease. I used openssl rand -hex <length> to securely generate these keys.

Here’s my full docker-compose.yml for reference.


Clickhouse can be incredibly resource-intensive unless configured correctly. Unless constrained and configured properly, it will happily consume almost all the storage and compute resources it’s given.


#Migration and admin setup

This is the point we diverge pretty hard from what’s defined in both the docker-compose.yml and from Plausible. The instructions there note a setup container, which is used to initialize Plausible, but then shouldn’t be run afterwards. Personally I don’t like this pattern, I’d rather the compose file contain exactly what’s needed to run the application, no more no less. Instead, we need to set up the databases manually:

  1. Start up everything except Plausible itself (docker-compose up -d db clickhouse)
  2. Enter the Plausible container (docker-compose run plausible sh)
  3. Create databases (/ db createdb)
  4. Run migrations (/ db migrate)
  5. Define your user credentials as environment variables:
  1. Create your admin user (/ db init-admin)

These steps only need to be done once, during application setup. After this, the command must be changed to automatically run migrations on start up. This ensures the database schema and running application are always in sync, and are updated with the container. This can be done by changing the docker-compose.yml like so.

Once the migrations have run, stop all the containers (docker-compose down), and start the all up as normal (docker-compose up -d).

At this point, Plausible should be accessible (however that’s configured).

Plausible login screen

#Installing into website

Now that Plausible is up and running.

The next steps are actually setting it up on your website, by far the easiest step! Plausible has some great documentation on both creating a site and adding the tracker script to your website, so there’s no point duplicating that here.

Here’s how I added Plausible to this site, and then promptly fixed.


If all’s gone according to plan you should now see page hits being tracked by Plausible, running on your own server. Amazing!

Share this page

Similar content

View all →

Self hosting my website

2 minutes

A few days ago, I was sharing a blog post to someone on the self-hosted podcast discord, and they asked if I was self-hosting my website. Unfortunately, and rather ironically, I had to answer no. I’ve been intending to move it over to my own server for a while, so…

Tea leaves with water droplets on them.

Plausible & Gitea

2 minutes

Yesterday, I moved my Git server from GitLab to Gitea. There’s nothing wrong with GitLab, I actually quite like it, but it’s a rather large tool for my needs. Gitea is much more lightweight, faster, and provides all its features for free. Now, it’d be nice to add some analytics…

Vintage page sheet background

Self-hosting static websites

9 minutes

Static sites, ie those which are just files on disk rather than requiring a custom application or database to run, are incredibly simple to write. You can either do it yourself from scratch with a bunch of HTML, CSS and JS files, or use a generator like Hugo or Zola.