Yes, it literally is though. Like what, you expect them to spend a month at sea?
Why should we join?
If you want to join a small instance hosted in Germany, that’s fast, reliable and run by an experienced system administrator. Or maybe you just like the domain name or something. The great part about federation is that it doesn’t really matter what server you use, join if you want.
What’s the purpose of this instance?
It’s a general-purpose instance, there’s no specific topic and can be used for whatever you want, as long as you follow rules.
What themes will your instance house?
Default themes. I don’t have any plans to add custom themes.
Deleting posts does make them difficult to search, but it’s inevitable that at some point that there’ll be searchable Lemmy archives (probably already exists tbh), If your ok with that.
If teddit and radarr are both on the same root domain, the radarr auth cookie may also be sent to teddit. This is because of the cookie’s domain and same site attributes. It’s probably nothing to worry about.
Are concurrent migrations actually a problem?
That might be the case, I wouldn't be confident reviewing it myself though since I don't know Rust that well and haven't used diesel before but I could ask the developers about it.
A mode in Lemmy to do nothing other than run migrations and exit.
I don't think there's a way to just run migrations like this.
Create my own DB migration script based on the Lemmy schema diffs from release tag to release tag.
Yeah maybe this could work?
Is there a config-flag on Lemmy to enable/disable db migrations?
There's a flag to disable scheduled jobs like you described but not for database migrations. I use that flag on all my Lemmy containers that serve requests, I have a separate container to handle the scheduled jobs and since it's just normal instance of Lemmy it runs database migrations on startup, so maybe one option would be to upgrade the jobs container first, wait for it to finish the migrations and then upgrade the rest. Obviously to do that with no issues or downtime the migration would need to be backwards compatible. The docs seem to indicate that this is possible.
As you note, run just one Lemmy container for “a while” when upgrading.
Yeah I feel like it would be a bit cumbersome and it would be nice to be able to do a rolling update with no downtime.
gfff
Hi, someone told me that lemmy.world is running a similar setup to mine and that you might have some insight.
For background, I've got my instance running on 3 servers, I've disabled the scheduled tasks on the Lemmy containers that are load balanced (I've got an extra container that does the scheduled tasks).
If you started up the Lemmy containers and they all tried to do a database migration, how do you handle this? Is the best option to just run a single process on an upgrade and wait until the migration is finished before starting up the others?
Awhile ago, I made like $300 with a bunch of Docker containers running brave browsers, I used a script that would open a bunch of sites, move the mouse around and then send the crypto to my site. It was so obvious, I have no idea how I didn't get banned (I'm still not), clearly whatever fraud detection they're using is pretty shitty.
Bitwarden is a pretty good option, it's fully open source and self-hostable and they get yearly security audits.