Yeah, this whole “Linux server” thing just isn’t going to take off.

Many “self hosters” simply aren’t comfortable with the basics and expect things to be just an app you install. A simple two-tier app/db architecture is too complex for them (hence the prevalence of sqllite these days).

I’ve run nextcloud for many years and was simply surprised to hear that it’s “difficult to manage and slow”. My experience has been quite the contrary - it’s been easy to keep up to date and has never failed an upgrade or lost data. And it performs “well enough” since I don’t use low-cost hardware for servers.

My only complaint is that I need to run occ from a terminal rather than having a web interface for it. Makes running it in a k8s pod kinda annoying.

This is the sort of thing bacula was made for - physical backups spread out over multiple removable media (tapes mostly, but it can work with optical drives).

https://www.bacula.org/free-tape-backup-software/

It tracks where it puts your files, so it does have its own db that also needs backing up. But if you want to restore without needing to search manually through dozens of disks this is what you need.

PHP does actually scale better than something like Lemmy which is written in rust

Okay - How then?

But sure, you can act like you know more than the Nextcloud devs

I’m a web developer too - so I feel rather qualified to speak on the subject. I don’t think the Nextcloud developers are some sort of genius team of engineers but I’m not saying they’re stupid or anything - just that PHP does not scale better than “practically every other technology out there”.

It forks or creates a thread per request. It’s horizontal scaling which is pretty common with any webapp. I don’t know why they claim PHP is special here. It’s a very common way to handle requests and you can do that with lots of languages and frameworks. More CPUs = more threads = more scaling. Throw more servers into the mix and you’re now “infinitely scaling” right? Well… No. Because I/O.

Webapps tend to be I/O bound rather than CPU bound. So asynchronous I/O leads to much better performance generally with fewer resources. Because no matter how many threads and servers you put in the app tier you’re going to be limited by the disks on your database at some point.

The scaling, in particular, is a huge benefit of PHP over practically every other technology out there: to double the performance of a PHP server, you can simply have twice as many cores and things will work without any changes needed. Not only is the scaling you get pretty much 100%, unlike other languages, this scaling continues beyond a single server!

There is so much wrong with this that it’s difficult to know where to start…

SRV records won’t help with browser traffic.

It’s bad form to just say “set this variable to this value” without any explanation about what that variable does and why that value helped.

Your configuration may not work or may be detrimental for others.

Others have written on the topic. Including Greg KH - one of the major Linux maintainers.

https://lkml.org/lkml/2025/2/19/222

memory safety isn’t impossible in C

In practice it is.

C is also faster than JavaScript, uses less memory, I wouldn’t consider a scripting language to even be a choice for writing a backend server if I can use a compiled language instead.

Neat.

No. Go away. That’s not “starting a social media app” now is it?

Besides, even the Linux team has started the shift away from C.

Edit: besides - “Linux does it” doesn’t mean it’s beyond criticism. Linux has had numerous security vulnerabilities due to C.

C is a “memory unsafe” language. There are whole categories of security vulnerabilities that simply aren’t possible in memory-safe languages that C allows. There is no good reason to continue using C anymore for new projects if you care at all about security.

https://www.cisa.gov/resources-tools/resources/product-security-bad-practices

Bonkers that anyone would start a social media app in C in 2025. “No JavaScript” but you’re just one buffer overflow from arbitrary code execution.

Free tier is a baiting strategy. Period.

Oh does it? I didn’t realize that. I’ve just switched over to rsync completely.

scp is deprecated.

Not in a VM is better usage - but “metal” refers to the hardware. Traditionally it’s used for embedded devices - no OS. But containers run on the hardware / OS in exactly the same way that non-containerized processes do. They even share the kernel of the same OS. There is no way non-containerized processes run on “metal” any more than containers do.

Inter-container communication is different. At least with docker which I have more experience with, but they’re similar. Try using the name of your container in your proxy config rather than the external host name.

Are these running on the same server? You haven’t given a lot of information here. Communication between containers is different:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/assembly_communicating-among-containers_building-running-and-managing-containers#proc_communicating-between-a-container-and-an-application_assembly_communicating-among-containers

“bare metal” does not mean “outside of a container”. Just say “outside of a container”.

It’s a losing battle, but I’ll fight it anyway.

If you’re just pulling “latest” then docker will fetch the latest when it starts. You can pin to a version tag if you want to keep it stable.