I was waiting for new versions, but the disk filled up faster than I expected. I'm moving 400GB image archive from local disk to object-storage. Unfortunately the process is very slow. It will take several hours.
I’ve read the cloud engineering headache write up from a few different Lemmy servers now so I no longer can remember which ones are on CDNs and which ones aren’t. Are you backed by anything in particular? Once you are on object storage you are likely to find a surprising egress bill if you aren’t caching the images and other content at a higher CDN tier.
You should also more or less immediately get lifecycle policies setup in your object store to tier older posts into cheaper storage. It’s 10-20 minutes of learning effort that stands to save you thousands of dollars. The trade offs with storage classes are usually cheaper storage as reads get more expensive. Since Lemmy promotes fresh content there is likely a balance you can strike in your lifecycle policies to drive storage costs down for older content that is unlikely to be loaded a ton of times.
Hey, I've noticed two things since the downtime and migration.
NSFW is no longer automatically checked on submissions. I can deal with that, but it used to be automatic here.
When I submit a new entry, the submission hangs with a spinning wheel. But I notice that the actual submission goes through. Don't know why the web server just hangs like that. But it is annoying.
Images are transcoded but thats not the problem. The problem is lemmy literally downloading every remote posts thumbnails to our archive. There is no option to opt out.
I looked at the images now and I will tell you for a fact that they are not being transcoded and saved. to transcode and save image to desired format you have to have set the following environment variable for the pictrs service in the docker-compose file: PICTRS__MEDIA__FORMAT=
When I look at your communities, I find images saved as png, jpeg, jpg, but not as webp. Saving images as webp/avif/jxl will result in an incredible reduction of storage requirements.