When you start self-hosting, you should be prepared for lots of troubleshooting, things not working as they should, and unexpected downtime. I would say that I've been quite lucky with the services I've chosen to use, with only one that stopped working for an unexplained reason after running smoothly for a while.

However, I recently learned the hard way what happens when you try to self-host too many services on an underpowered device — in this case, my Synology NAS.

Why I self-host on an underpowered NAS

Better hardware and upgrades are expensive

If I had a dollar for every time I've been told I can get started self-hosting for cheap, I'd have a full-fledged home lab by now. The reality is that the cheapest way to get started is to use what you already have. There are ways to access additional hardware and upgrades at a lower price, but this greatly depends on where you live.

In my case, I live in South Africa. Electronics are expensive due to import taxes, sales taxes, and limited local competition and manufacturing. Even the cheapest refurbished mini PCs, which are over a decade old, cost at least $75 here, even with discount. Most people don't have spare devices lying around because we tend to use them until they break or sell them in order to offset the cost of an upgrade.

I started self-hosting on my main PC for this reason. Eventually, due to the inconvenience of not having round-the-clock access to important services, I took out the NAS that had been lying around for years and gave it a go. The NAS was an old review device, which is the reason I had it. While I have ample storage for it, it has a major limitation: only 2GB of RAM. A 4GB RAM upgrade would set me back $115. This might be worth it for some, but the reality is that I just don't have the disposable income at the moment due to medical costs.

When I started switching my self-hosted services to my NAS, I realized my RAM constraints would limit what I could host on the device. It's a big reason why I use a Home Assistant container rather than HAOS. I have been quite restrained about what I move to the NAS, reserving it for containers I want 24-hour access to. As a result, it sits at about 60% RAM usage. Because of this, I haven't bothered self-hosting LLMs or using AI-heavy services.

Things went relatively well for months, but then this limited RAM came back to bite me when I hosted a container that was more demanding than I expected.

One service tipped things over the edge

But the effect was delayed

I always test containers on my main PC before moving them to my NAS. This makes sure that I like the service enough to continue using it, but also ensures that I have done the troubleshooting and configuration needed to confirm that it actually works. My Docker UI is different on my PC and my NAS, so I want to remove as many variables as possible in case I run into issues.

When I set up Paperless-ngx in a single afternoon, I was impressed by how useful the service was. Using the companion mobile app, I was able to quickly upload documents and sort them by various tags. So I decided to move the service to my NAS, but I started the database from scratch since the container on my PC was just a quick test.

Things went smoothly at first. The container started up easily. I connected the mobile app to my NAS and began uploading documents. I did notice that it was much slower, but I shrugged this off because even Immich works more slowly on my NAS due to the less powerful hardware.

Eventually, though, the Paperless app kept disconnecting. I investigated the service on my NAS and noticed the container kept crashing. Each time I started it up again, it would stop unexpectedly. It also triggered a domino effect, where all my other containers stopped.

My browser would no longer connect to my container, and my NAS UI kept freezing. My entire system essentially became unusable.

Luckily, I could recover

My other containers could restart

Eventually, I realized that my NAS resources were overburdened. I tried to check what my Resource Monitor widget showed, but the UI was not loading properly by then.

Once I stopped trying to restart Paperless-ngx, the other containers restarted without issue. But my Paperless-ngx server was essentially bricked. This was because the mobile app had pending documents that needed to be uploaded, and processing these would cause the server to crash.

While my logs weren't particularly detailed, I suspect this is because of the OCR and AI tagging features built into Paperless-ngx. Uploading a single file didn't cause many issues, but as soon as I started uploading multiple documents at once, my device's resources were overwhelmed.

I eventually settled on using Paperless-ngx on my main PC. This allowed me to quickly upload documents with no difficulties. The important difference is that my computer has a much more powerful CPU and 6GB of RAM allocated to Docker.

Even when I restarted my Paperless-ngx container on my NAS weeks later, I saw the Resource Monitor statistics jump — even though the entire server had only three documents and no new uploads since the botched attempt before. The CPU and RAM usage eventually stabilized, but I know that if I try to upload anything else, I'll likely trigger the domino effect again.

However, to keep an eye on my system resources, I have set up a warning on my NAS to notify me if my RAM usage reaches 80%.

To be clear, this isn't a problem with Paperless-ngx. I still think that the service is great and provides awesome functionality for a self-hosted tool. But if you're using a device with limited resources, it's important to be conservative with what you want it to do.

There are some things you only learn by doing

While there are plenty of things that people over-simplify about self-hosting, there are also some things that you can only learn by doing. For some services, there will be clear requirements for the amount of processing power you need. But for others, it will depend on the tasks you want to complete.

I'm just glad this mistake didn't have long-term consequences and turned out to be just a temporary inconvenience.