We try to give some details on our current plans in our blog posts for significant releases. At the moment we are reviewing issues and requests while also adding more features for uptime monitoring.
@james.kiger:burkesoftware.com I can't say as how this seems like something you have any incentive to do from a business perspective, but I'd like to see a bit more information on how to set it up well for a more scalable deployment; I run in kubernetes and am particularly interested in seeing how to use existing services where appropriate (e.g. postgres, though that's not hard), if there are components which can be run in parallel either to handle more traffic or provide failover in case of a server outage, etc.
Granted it's been awhile since I last looked at what you have, so maybe you've done that more. I tend to overengineer and overmonitor my stuff -- I end up with way more traffic than I could afford to pay for on a SaaS basis but want to be able to handle it on my cluster since that (also being overengineered) has surplus resources
@taxilian: I don't think we have much to talk about high availability besides try kubernetes or similar scaling approach. You may find this existing page interesting https://glitchtip.com/documentation/hosted-architecture
If you have any questions on how we run it, I'd be happy to expand these docs. Right now we increase the # of kube pods and size of the managed DB when we need to scale. But honestly it's not a huge scale right now.
Our helm chart is reluctantly getting more robust over time. We now have a real helm chart repo thanks to gitlab. I say reluctantly because it's hard to make everyone happy with kube and it's too complex for basic use cases.