kyrylo

We Use Rails is a directory of Ruby on Rails web apps. I launched it a year ago, and since then it has received over 150 submissions.

Christmas is special for all Rubyists thanks to the annual Ruby release, so I decided to tag along and join the Xmas party. This is my humble contribution to the ecosystem. Enjoy!

What specifically draws you to Sentry over self-hosting or smaller players? Would an indie-hosted alternative (with similar privacy guarantees but more personalized support) appeal more?

Would you rather pay a big corp or an indie business to host your errors?

Wouldn’t it be cheaper to just pay for a ONCE-style product like Campfire? It’s not that expensive compared to what companies spend on Slack. Then when the time comes, you can switch to Teams (having saved thousands in the meantime).

Appreciate the answer! You’ve probably worked with raw SQLite drivers. I’m using a framework, which likely runs more transactions by default. I’m fairly confident that with a bit of digging, I can improve the ingestion speed. Good to know and thanks for sharing your experience!

What’s your experience with SQLite? It’s a bit hard to talk about performance without sharing code.

Fizzy uses SQLite for multitenancy. I suppose that’s why it takes up so much of their time. Being a fan of SQLite, I hope this approach succeeds. P.S. I know Campfire has made “six figures”

It uses SQLite as its database.

I follow 37signals updates on ONCE, but I don’t recall them mentioning sustainability issues. Could you share a link?

Thanks for the suggestion! A hosted solution could definitely be an option. That said, some people have mentioned that having an indie dev behind it can be a turn-off. I’ll keep exploring ideas that make sense, though.

I appreciate the feedback. I’ve updated the information to remove the WordPress reference and clarified that the OS must support containerization. Thanks!

Telebugs isn’t meant to be a full Sentry replacement. It focuses purely on error tracking. The goal is to avoid feature creep and do one thing exceptionally well, much like classic UNIX tools. That said, you’re not the first to ask about APM features, and it’s motivating me to consider building a separate APM product.

That’s a fair concern, but I see it differently. Software can reach a point of maturity - not “dead” just done. That’s the whole philosophy behind ONCE: build something great, maintain it responsibly, and stop when it’s complete.

Yeah, I used it as a starting template. But beyond the layout, the copy and product are completely different. It just helped me get started faster, and I’ve always been open about that. Everything else (including the installer) is fully self-made.

Thank you!

Not at the moment, but I’m open to it! If you have something in mind, feel free to email me at [email protected] and we can work something out.

Nope, there are no APM features in Telebugs: https://telebugs.com/#okay-but-sentry-offers-apm

Fun fact: Telebugs itself runs on SQLite3!

That's a fair point. In my case, though, I'm a solo dev without a hardware ecosystem, so major versions help sustain development without forcing subscriptions. What do you think about models like that for indie projects?

Telebugs creator here. GlitchTip is solid, but Telebugs is built for devs who want something lighter and faster to self-host.

It runs on plain Rails, sets up in about 5 minutes (one command), and stays snappy even on small servers. The UI is modern, minimal, and actively maintained. I keep refining it to stay fast and clean.

The biggest difference is in philosophy. GlitchTip was built by an agency. Telebugs is a solo passion project. I’ve worked on error tracking tools professionally before, and built Telebugs to reflect how I wish those tools worked.

If you’re curious, here’s a short write-up on why I built it: https://telebugs.com/why

Happy to answer any specific questions!

ONCE projects do get occasional updates. I don’t use boilerplate projects much, so I can’t speak to them.

My model isn’t a subscription. Think about it like buying rice. You might buy it every week, but that doesn’t mean you’re “subscribed” to rice.

Even if I release a new major version, you’re free not to update. And if it’s a major version, it’s fair to expect it to be paid. After all, major updates usually bring significant improvements. For example, if you played the original DOOM, you had to pay for DOOM 2 too, even though they run on the same engine.

Thanks for your answer! Would you mind sharing your error volume? I’m also curious, how often do dropped events happen, and how does it impact your workflow? Any workarounds you’ve tried, or features you wish were available? This will help me make sure the feature is implemented in a way that’s actually useful.

Hey, Telebugs creator here. Great questions! Right now, Telebugs doesn’t have built-in throttling, so during error spikes, you’d either need to handle it manually or overprovision. I do plan to add throttling in the future, similar to what Sentry does, to protect your infrastructure automatically.

Curious: for those running self-hosted error trackers in production, how do you currently handle sudden error spikes? Any clever tricks or patterns you swear by?

> Look at all the one off payment products that involve code, they're all dead.

Could you share some examples? I can’t think of any off the top of my head.

--

I really went all-in with the ONCE philosophy because it resonated with me deeply. It felt more like a passion project than cold business strategy.

Thanks! I’m not really competing with Sentry itself. I’m competing with self-hosted Sentry, which is notoriously hard to install and maintain (and has steeper hardware requirements).

I'd say my customers prefer my product because:

- They want self-hosting without the maintenance burden.

- They work in regulated or internal networks.

- They’re tired of subscription pricing.

- I build it in public and post regular updates on my social media.

- They value direct support from the creator.

P.S. I’ve personally worked for a Sentry competitor, so I know the pain points firsthand.

Haha, true. I used to rock Arch Linux back in 2012–2015, so no need for Omarchy for me