Last month we walked through standing up Nextcloud on your own server. A reader emailed us afterward with a fair question:
“Okay, it’s installed and my team is using it. Now what? It just… runs, right?”
That question is where most self-hosting stories quietly go wrong. The install is a finite project with a satisfying finish line. What comes after has no finish line at all — and it’s the part that determines whether owning your data was a smart move or an expensive lesson.
So let’s talk about the jobs the cloud was doing for you invisibly, that are now yours. None of them are glamorous. All of them are the difference between a reliable system and a breach.
Job 1: Patching, on a schedule, forever
Every piece of your stack — the operating system, the database, the web server, the language runtime, and the application itself — ships security fixes continuously. When a vulnerability is announced, the clock starts: attackers begin scanning the internet for un-patched systems within hours.
Patching sounds trivial until you’re doing it for real:
- You can’t just blindly update. An application update can break a feature your business depends on, so you test first — ideally on a staging copy, not on the server your team is actively using.
- The components patch on different schedules. The OS, the database, and the app don’t coordinate. You’re tracking several update streams at once.
- Some updates require downtime, which means doing them after hours, which means someone’s evening.
- Skipping is invisible — until it isn’t. An un-patched server shows no symptoms right up until the moment it’s compromised.
The cloud did this for you silently, on a team’s full-time schedule. Now it’s a recurring calendar item that never goes away.
Job 2: Backups you’ve actually tested
Everyone agrees backups matter. Almost nobody tests them, and an untested backup is just a hope with a filename.
Real backup discipline for a self-hosted system means:
- Capturing the whole picture in sync — the files, the database, and the configuration, taken consistently so they restore to a coherent state.
- Automating it so it happens whether or not anyone remembers.
- Storing copies off-box and offsite. A backup on the same server is useless when that server dies. A backup in the same building is useless when that building floods — which, in Houston, is not a hypothetical.
- Keeping it out of reach of ransomware. Modern ransomware specifically hunts and encrypts backups. Yours need to be somewhere the infection can’t follow.
- Restoring it regularly, on purpose, to prove it actually works. The worst time to discover your backups have been silently failing for four months is the day you need them.
This is the single most-skipped responsibility in self-hosting, and the one that turns a recoverable bad day into a company-ending one.
Job 3: Monitoring — finding out before your customers do
When you own the infrastructure, there’s no provider watching it for you. If a drive fails at 2 a.m., or the disk fills up, or a backup job dies, or someone is brute-forcing your login page — something has to notice and tell you. “I’ll check it when I think of it” is not monitoring.
Proper monitoring means automated alerts for, at minimum:
- Disk space filling up (a server with a full disk simply stops working, often corrupting data on the way down)
- Failed backup jobs
- Services that have crashed or stopped responding
- Certificate expiry approaching (an expired TLS cert is an instant company-wide outage)
- Unusual login activity and brute-force attempts
- Drive health warnings before the drive actually dies
Good monitoring is what lets a self-hosted system be more reliable than the cloud instead of less. Without it, you’re flying blind and finding out about problems from your angriest employee.
Job 4: Security, as an ongoing practice
Securing a server isn’t a setting you flip once. It’s hardening the configuration, enforcing two-factor authentication, locking down what’s exposed to the internet, watching the security advisories for your specific software, and responding when one lands. The threat landscape moves; a system secured in January and ignored since is not secured in July.
The honest tally
Add it up and self-hosting carries a steady, unglamorous workload: patch, test, back up, verify the backup, monitor, respond to alerts, harden, repeat — indefinitely. None of it is rocket science. All of it requires someone to consistently care, have the skills, and have the time.
For a business owner, that “someone” is the whole question. It’s one of three people:
- You or a staff member, paying for the “free” software in hours pulled away from running the business — and hoping that person doesn’t quit, get busy, or get it wrong.
- Nobody, which is the most common and most dangerous answer — the system runs un-patched and un-monitored until the day it doesn’t.
- A professional whose actual job is to keep it patched, backed up, monitored, and secure.
This is the job we do
Here’s the honest pitch. The reason our on-premise and open-source service isn’t free isn’t the install — it’s everything in this article. We do the patching on schedule, run and test the backups, monitor the systems so failures get caught early, and keep the security current. That ongoing discipline is the entire value, and it’s why we charge professional rates for it rather than handing you a server and walking away.
You get the data ownership. We carry the jobs that make it safe to own. If you’re running something self-hosted right now and you’re not 100% sure your backups have ever been restore-tested, that’s the conversation to have — book a free discovery call and we’ll do a straight assessment of where your setup actually stands.
Aspendora Technologies provides cybersecurity, managed IT, and expert on-premise & open-source solutions to Houston-area small businesses since 2010.