I can only see this being effective if the Nginx instance isn’t also responsible for reverse-proxying the frontend traffic, and if it’s not running on the same server as the frontend or backend (ie. decoupled from the infrastructure serving the stack). Haven’t looked at the article yet but I’m assuming they would recommend provisioning the infrastructure with that decoupling, or it wouldn’t make much sense.
Same here, I’ve never had this problem, ever. I don’t even get how it’s possible to not know where your files are being saved if you are the least bit techsavvy.
I’ll update to a newer Postgres version and report back. It would be nice to know what the minimum supported version is, maybe that should be added to the documentation.
EDIT: Upgrading to Postgres 15 resolved my issue, but not without some pain since the migration scripts had already tried to run on my Postgres 13 database. So after dumping the 13 database, I had to make some modifications after the fact to satisfy the migration scripts. It was a pretty janky process but I seem to be in a good place now.
I would highly advise communicating to people that they should upgrade past Postgres 13 before trying to upgrade Lemmy to 0.18.3 or higher, or you’re gonna have a bad time.
Ran into this issue with database migrations:
Failed to run 2023-07-08-101154_fix_soft_delete_aggregates with: syntax error at or near "trigger"', crates/db_schema/src/utils.rs:221:25
Will open an issue on GitHub.
To be more accurate, I actually self-host Vaultwarden, which is a Bitwarden-compatible server built in Rust. I highly recommend it, it’s quick and easy to setup, light-weight, and works with all of the Bitwarden apps, browser extensions, etc.
I keep all secrets and passwords in a selfhosted Bitwarden instance. I don’t maintain any kind of “documentation” since my deployment files and scripts are clean and tidy, so I can tell what’s going on at a glance by looking at them directly. They’re also constantly changing as I continuously harden services according to ever-changing standards, so it’s more efficient for me to just continue keeping my codebase clean than it is to maintain separate documentation that I myself will likely never read again once I’ve published it.
I’m the only one that needs to know how my own services are deployed and what the infrastructure looks like, and it’s way faster for me to just look at the actual content of whatever deployment files or scripts I have.
It’s a different story for things I work with professionally, because you can’t trust someone else working to maintain the same things as you has the same level of knowledge to “just know where to go and what to do”. But that doesn’t apply to personal projects where I just want to get things done.
I run all of my services in containers, and intentionally leave my Docker host as barebones as possible so that it’s disposable (I don’t backup anything aside from data to do with the services themselves, the host can be launched into the sun without any backups and it wouldn’t matter). I like to keep things simple yet practical, so I just run a nightly cron job that spins down all my stacks, creates archives of everything as-is at that time, and uploads them to Wasabi, AWS S3, and Backblaze B2. Then everything just spins back up, rinse and repeat the next night. I use lifecycle policies to keep the last 90 days worth of backups.
You shouldn’t be charged for unauthorized requests to your buckets. Currently if you know any person’s bucket name, which is easily discoverable if you know what you’re doing, that means you can maliciously rack up their bill just to hurt them financially by spamming it with anonymous requests.