AFAIK the todo list is still valid. The generic points on it aren’t real blockers though. You can already install on a AWS VM but you won’t get an automatically up-gradable system until we get to providing distro packages.
The amazon specific things (cloud-init and S3) haven’t been touched at all. I have a feeling that the S3 support might be the one you really need, using local storage on a cloudy VM only makes marginal sense.
Personally I’ve been working on an OpenShift/k8s deploy. Once done that might also be an option for cloudy deploys. I feel like the k8s way will mostly be interesting for users that already know the technology. New Linux users should probably stick to a VM for the time being.
BTW, I had some success with a cloud-init based install on dply.ch (digitalocean based) and documented what I did here. It’s a bit outdated and I had issues with using dply.co and haven’t tried anything there recently.
Cool, yeah I’m running LibreTime on a amazon AWS but mainly as a poor persons stream relay and with a local storage as @hairmare mentioned. Distro packages are still a goal at some point and someone would have to take an interest in the S3 stuff as I don’t think it’s a high priority for any of the devs at the moment.
Thanks for the updates! Personally I’d still like to help make a LibreTime equivalent of https://www.airtime.pro/ possible.
Going on the assumption the reasoning for keeping a SaaS offering separate the OSS project still holds true, it sounds like the best bet is to direct any interested developers and AWS specialists to the checklist @hairmare provided in the github issue.
Aside from the billing and quota management etc, it is possible to run LibreTime on AWS. I think if anyone did want to create a SaaS installable version the only thing they would need to keep in mind is the requirement of the AGPLv3 that they share all of their source code changes etc.
Ok - so this will probably contradict what we’ve been discussing… but
what if LibreTime did provide a SaaS version in addition to the free download? The actual hosting service could be handled by a partner and/or interested community members. Rather than a full on customer offering, there could be more of a white label/vendor focus.
I think a hosted version would be attractive to small stations, podcasters, or individuals who don’t have the skills or resources to set up and maintain their own instance. It should also provide an ongoing funding source for the OSS project and community. If LibreTime was set up on OpenCollective, there’s potential for hosting as a perk which can then be used to fund work on distro packages and other features/functionality needed.
I do think this could be a way to sustain and grow the project if done right.
On a side note, I’ve seen slow but steady progress with my pet project LibreTime docker images and helm charts for Kubernetes. They are still far from alpha at this point but I think I’ve got all the bits and pieces together for integrating into the ecosystem. As far as I can tell my work should be deployable on most public clouds (ie. Amazon Elastic Container Service, Azure AKS, Google GKE and others).
The thing is my personal containerization effort is really just a pet project at this point and it won’t get production ready any time soon. There is lots of grunt work to be done in making LibreTime run HA enough for all of this to make sense at scale.
We’ve been using Airtime 2.5.1 on AWS for more than 3 years now. Would love to have done things like use RDS for the database but it was so old that it wasn’t a viable thing to get working. Instead I have scripts that dumb the database every night and copy it to an S3 bucket. I even backup the /srv/airtime/stor folder to an s3 bucket (I’ve totally destroyed our production aritime DB twice it’s an interesting story).
Also I’ve always had a history of the icecast not working well with the default Airtime install … and so far I’m kinda having the same issues with LibreTime … but one thing we do is we also have a separate machine just running shoutcast and we use that for our internet streaming instead of the default icecast installed with airtime. Anyway I mention that because in terms of AWS we’ve got two machines running, one for Airtime and another for shoutcast (which hosts 5 different streams).
Curious…Those hosting on AWS, what’s the specs on your EC2? How much cpu and ram would I need in order to reasonably run Libre Time in production? Thanks.
The processing required by LibreTime is pretty minimal except for when importing tracks, applying replaygain and all of the other processes. A T3a.micro 1GB instance can run LibreTime. You need at least 2 processors, which the T3 EC2 machines have otherwise the system will have a hard time context switching between the web UI and the CPU intensive track analysis.
The questions become are you going to use an external Icecast/stream or have everyone pointed at your instance of LibreTime. Bandwidth costs can be significant with EC2 and hard to control unless you have a proxy. But on the other hand you can benefit from near unlimited capacity for listeners.
My station has a self-hosted transmitter located instance of LibreTime and utilizes EC2 just to act as the Icecast and web server although I did setup a backup/testing instance of LibreTime on a T3a.micro tier and it seemed to work but is not in “production”.
TechSoup resells Amazon credits to US based 501c3 non-profits but I think they tend to sell out of them rather quickly. It is something like $200 for $2000 AWS credits, which makes utilizing Amazon almost worth it. The challenge is in the obtuse billing and management dashboard which requires you basically to become an expert in the AWS way of doing things and to think about how to budget costs appropriately and insert your own limits.