The price hike is steep. They've gone from a simple "per site" model to this convoluted "pageview" tiering. It's a classic bait-and-switch pattern.
For a simple internal dashboard with low traffic, maybe it's still fine. But if you have any real volume or public-facing analytics, you're now incentivized to sample your own data or cut back. That defeats the purpose. You can replicate the core privacy-respecting functionality with a self-hosted Plausible instance and an Ansible playbook. The operational overhead isn't zero, but at least the cost is predictable and you control the data plane.
```yaml
# ansible/plausible-deploy/main.yml
- hosts: analytics_servers
vars:
plausible_version: "latest"
tasks:
- name: deploy plausible with docker compose
community.docker.docker_compose_v2:
project_src: "./compose"
state: present
```
Now you're dealing with backups, updates, and incident response instead of a bill. Pick your poison.
Don't panic, have a rollback plan.
I'm a director of platform engineering for a mid-sized SaaS company (about 120 engineers). We run a multi-tenant analytics platform serving 50+ customer-facing dashboards, handling roughly 15-20 million pageviews monthly. I've been responsible for our analytics pipeline cost for three years, evaluating everything from full-service vendors to self-hosted open source.
- **Pricing Predictability:** The new pageview tiering creates a variable, traffic-dependent cost. For a public product, this directly ties your cost to user growth, which can scale uncomfortably. Our old 'per site' bill was ~$650/month. Under the new model, our estimated cost jumps to ~$2,200/month. A self-hosted Plausible stack on three managed Kubernetes nodes (for HA) in our cloud costs us ~$285/month, fixed, regardless of traffic volume.
- **Deployment & Operational Lift:** The SaaS offering wins on deployment (near-zero). A production-ready, self-hosted Plausible deployment requires more than a docker-compose file. You need to handle HTTPS/TLS termination (certbot or ingress controller), database backups (automated PostgreSQL dumps to object storage), high-availability (at least two replicas for the app and DB), and a reliable update pipeline. In my environment, this translates to about 4-5 hours of initial setup and 1-2 hours per month for maintenance and updates.
- **Performance & Scaling Limits:** The SaaS solution handles all scaling automatically. Our self-hosted setup (Plausible v2 on EKS with 2 app pods and a 4 vCPU PostgreSQL RDS instance) holds steady at ~2,500 requests per second before latency increases. For us, that's a comfortable buffer. If you suddenly get a Reddit front-page spike, the SaaS vendor absorbs that; with self-hosted, you need alerting and auto-scaling configured, which adds complexity.
- **Data Control & Compliance:** Self-hosted is a clear win for data sovereignty. With the SaaS, your analytics data resides on their infrastructure, which can be a blocker for certain industries or customer contracts. Hosting it within your own VPC means the data never leaves your cloud perimeter, simplifying compliance narratives for legal and security teams.
Given the steepness of the new pricing curve, I'd recommend self-hosted Plausible for any team with in-house platform/DevOps skills and a traffic profile above 5 million pageviews per month. For a simple internal dashboard or a low-traffic public site (under 500k views), the SaaS is still the better choice to avoid operational burden. To make a clean call, tell us your exact monthly pageview band and whether you have a platform team that can own the deployment.
every dollar counts
Your point about the deployment and operational lift is spot on. For a company your size, that ~$285/month fixed cost for the infra is only part of the picture. The fully-loaded cost includes engineering time for the initial setup, ongoing maintenance, security patching, and scaling the stack.
That said, at your volume (15-20M pageviews), the SaaS cost delta is so significant that it likely funds a half-day of an engineer's time each month. You could allocate that to managing the self-hosted setup and still come out far ahead. The key is automating the operational tasks you mentioned into your existing GitOps pipeline, treating it like any other internal platform service.
Did you run into any specific snags with the high-availability PostgreSQL setup or the metrics aggregation at that scale?