← All Posts

How to Raise the API Rate Limit for Self-Hosted Plausible Analytics

If you're running Plausible Analytics on a virtual machine (or some other box), you don't need to abide by the default API key rate limit it enforces. Let's walk through how to raise it.

I’ve been using the self-hosted version of Plausible Analytics for a couple of years now, and I’ve really enjoyed it. One of the many perks of the self-hosted model is that I’m able to do what I want with my data as often as I want to do it.

For example: this is statically generated site. Every time it builds, I pull in the latest analytics data from the Plausible REST API to render on various pages, including my personal dashboard. By default, there’s a rate limit set in place – 600 requests/hour. That’s usually a suitable default, but it’s occasionally not. Fortunately, being self-hosted, it’s easy enough to raise that limit to something astronomical. Let’s walk through it. Heads up: I’m assuming you’re on a virtual machine that you can access via SSH (mine’s on DigitalOcean).

Accessing Plausible’s Postgres Database

Access the machine and cd to wherever your instance of Plausible is living:

Terminal window
# replace with your VM's IP address:
ssh root@123.456.789.101
# replace with wherever your instance lives:
cd /opt/plausible

Next, we’ll need to find the name of the container in which Plausible’s Postgres database is running. Run docker ps and you’ll see a list of running containers. You’re looking for the name assigned to the one using the postgres:VERSION image:

docker ps

Now, we’ll access that container with psql, logging in under the postgres user:

Running \l should show every database running in the container:

docker ps

Run \c plausible_db to connect to the database we’ll need:

docker ps

We’re in. Next up, let’s find the table and raise that API limit.

Raising the API Key Limit

The table we’ll need to update is api_keys. Just for sanity’s sake, go a head and view the records in there. Assuming you’ve already generated a token (if you haven’t, do it), you’ll see something similar to this: As might’ve guessed, we’re interested in that hourly_request_limit field. That field is an integer type, which has a maximum value of 2,147,483,647. So, let’s update it:

UPDATE public.api_keys SET hourly_request_limit = 2147483647;

You did it.

But before you move on, keep a couple of things in mind:

  • This change won’t impact any keys you add in the future. If you add any later, you’ll need to run through this process again.
  • There are reasons rate limits exist in the first place. You’re virtually removing it here, so think about the potential performance and security implications of that decision.

Hope this is useful to someone!