Hi guys, I’ve been working on a self-hostable web analytics platform since the start of this year after being frustrated with Google Analytics and Plausible.
I’ve packed a bunch of cool web analytics features into Rybbit, but I’ve tried very hard to keep the interface simple to use,
https://github.com/rybbit-io/rybbit
Check it out!
I would love for this to work on yunohost.
Just a word of warning for everyone: The free self hosted version is heavily limited. I will stick with Plausible which may be simpler but also doesn’t want to push me into a subscription.
as opposed to plausible community edition which is even more limited and is only updated a couple times a year?
The community edition allows me to have multiple sites, multiple users and is way easier to set up. If I ever need additional features like funnels I would need a subscription for both - Plausible is less expensive.
Question is the self-hosted version less featured than the paid hosted version?
This looks amazing btw.
Only very slightly so. One of the reasons I created Rybbit is because platforms like plausible and fathom have much inferior self-hosted versions (very limited featureset and basically never updated). We have a comparison here
@Goldflag
I appreciate the intent behind Rybbit, but I have to respectfully disagree with the “only very slightly so” characterization. Looking at your official comparison table, the self-hosted version is missing:
- Pages View
- Web Vitals
- Email reports
- Google Search Console integration
- VPN/Crawler/ASN tracking
- Google/GitHub OAuth
- Email support
That’s 7 significant features—which seems more than “very slightly” different.
More importantly, this raises AGPL compliance questions. Under AGPLv3 Section 13, if users interact with modified AGPL software over a network (your cloud version), you’re required to make the complete corresponding source code available to those users. If these cloud-only features are integrated into the same AGPL-licensed codebase, withholding them from the public repo while running them as a network service appears to conflict with the license terms.
There are really only two compliant scenarios here:
- These features exist in the public repo but are just marketed as “cloud-only” (in which case the comparison table’s misleading)
- These features are truly separate proprietary code that interfaces with Rybbit without being part of the AGPL-licensed work (which would require careful architectural separation)
If it’s neither—if these are AGPL-covered features running in your cloud service but withheld from the repo—that’s exactly the “loophole” the AGPL was designed to close. The irony is that you criticized Plausible and Fathom for having “much inferior self-hosted versions,” yet this appears to be a similar approach.
Could you clarify the licensing status of these cloud-only features? Are they in the public repo but disabled by default, or are they proprietary additions that don’t derive from the AGPL codebase?
OAuth is one thing I hate to see locked behind a paywall; it’s one thing for the pretty, management-geared stuff (dashboards and charts) to be a paid feature, but not security.
AGPL means they are licensing it to you, they are not bound by the license because they are the copyright owners.
That’s misleading. While copyright owners aren’t bound by their own license, AGPL Section 13 requires that when they run AGPL software as a network service, they must make the complete source available to users.
The AGPL was specifically designed to close the “SaaS loophole.” Being the copyright owner doesn’t exempt you from AGPL’s network service requirements if you’re distributing under that license.
This is flat out wrong. If you’re the copyright owner, you’re not licensing the code to yourself. The AGPL is the license under which they’re making the open source version available to YOU. The version they run themselves is proprietary.
That’s inacurrate. Licensing representation matters. If the cloud service is genuinely presented as AGPL-licensed, Section 13 obligations apply regardless of copyright ownership. However, copyright owners remain free to maintain truly separate proprietary versions under dual licensing.
Licensing representation matters
It doesn’t, because they’re the copyright owners. Think of their software as dual licensed: They run it themselves under a proprietary license, under which they reserve all rights. That has nothing to do with the AGPL version that they license to you. The AGPL doesn’t take away the rights they have as copyright owners, nor does it preclude dual licensing.
(Are you a bot? Your reply is written like ChatGPT, and it has that self-defeating logic that ChatGPT has sometimes… eg. you wrote that you disagree with me, but then parroted the exact thing that I said.)
Docker is a security risk. Is it possible to install securely?
Docker is a security risk? … excuse me, what? Can’t you just, idunno, secure the environment that docker runs in? Use rootless images? Use immutable images?
And, are you asking for something that runs on bare metal? Couldn’t you just install the ISO that the dockerfile uses, then convert the dockerfile logic to an sh script?
Doker pull is insecure
It’s the download that’s not verified
You can verify the checksum to ensure the contents pulled are exactly the same as what was published. You can also use a private container registry.
How exactly would docker pull be any more insecure than something like pip install? Or, really anything… Let’s go with your preferred alternative, how are you going to get it on your machine in a more secure way than docker provides?
Docker uses TLS with registries, layers and manifests have cryptographic digests, checksums, and you can verify the publisher yourself. Push it into your own registry if you want, or just don’t use
latest.Yeah, that’s the insecurity I’m talking about.
If you want to know how to implement this properly, look at apt. Its a known issue in docker; they just haven’t prioritized the fix yet (DCT)
What are you talking about, “yeah that’s the insecurity I’m talking about.”
I didn’t mention an insecurity and neither have you. Would you mind being a little more clear than “Docker pull is insecure?”
Frankly, I was expressing confidence in dockers security. It goes without saying though, any user can do insecure things like download from untrusted sources. That’s not dockers problem though, it’s the users.
Edit: I see now that you added “it’s the download that’s not verified.” Integrity is verified, so I assume you mean authorship (via signing)? I guess you’re saying that, if admin credentials are stolen from a container publisher and the thief force pushes malicious code into the registry under a pre-existing tag—then you would be exposed to that?
Even in that case, though, a digest cannot be overwritten. Tags can. So you’d just pin the digest to avoid this one attack vector?
Checksums are not for security. You need signatures. I’m not making claims that aren’t clearly documented.
I imagine you can use Podman instead
I think that has the same problems, no? Or does podman do signature verification on all the layers it downloads from the container registry?
Podman runs rootless by default
You didnt read what I wrote. The security problem is how it downloads layers. It doesn’t verify them.
