Thanks for sharing this! I'd love to see a section in the readme comparing this to other s3-backed kafka replacements such as warpstream and bufstream, and why you'd use this over those.
Creator here... I built this because I wanted to keep track of the apt packages that needed updating on my servers, and forwarding apticron emails to Slack just didn't do it for me.
We (honeybadger.io) are open to spinning up an EU-hosted version of our service. Those who would like to signal their interest in that can contact us at [email protected]. :)
We did a private beta when launching Honeybadger.io, and it worked really well. We reached out to people we knew who would be good customers, had them go through the same signup flow we planned to use after launch, and had them enter payment information and get billed (so we could test everything). We offered these first customers a special, low-priced plan as a thank-you for helping us test the product.
I think it would be fine to do manual invoicing for this group of customers if you don't have your credit card processing in place yet. These first customers should be ones who will understand that they are testing, so not everything will work. On the flip side, though, you should be prepared to offer them excellent service, responding quickly to any issues they encounter. These customers can become a great source for referrals for additional customers if you treat them well, so treat them well. :)
Since you have nothing in place at the moment, I recommend you get something in place while you are evaluating your options.
At honeybadger.io we use papertrail for log monitoring, and we love it, but there are plenty of hosted options. Set up a free trial and you'll at least get aggregation and monitoring now, plus an idea of what kind of logging volume you'll need to support with your self-hosted solution.
We are using Elixir/Cowboy at https://www.honeybadger.io to receive log drain data from our customers' Heroku apps. It's reliable and fast, but deployment has been a sort point (we're spoiled by Capistrano). I recently changed the deployment to elasticbeanstalk with the multiple docker image approach, and that has been much nicer.
The ecosystem is still young -- a lot like Rails was in the early days -- so there are rough edges, but I'm betting they will get sorted out, just like they did in Rails land.
Our preferred deployment method at Honeybadger is to (almost) always merge to master before deploying. We will deploy a feature branch when we want it to be a little easier to rollback to a known good state (by deploying master) for changes that we are nervous about. Those deployments are rare, though, as we have an almost-production environment (it talks to all the production services, but no customers use it) for doing one last smoke test before unleashing code on customers. :)
"Based on the output of running forkwatch against the maximadeka/convertkit-ruby repo, what would you suggest for a PR to that repo?"
That resulted in Claude forking the repo, applying patches from the forks and offering to open this PR: https://github.com/maximadeka/convertkit-ruby/pull/41