Self-Hosted Cloud Storage: Tier, Don't Migrate

What You’re Actually Deciding

The word “control” gets used loosely here. It is worth separating, because it is three different questions with three different answers, and most people only notice the first one.

Control over your account. Can the thing holding your files take them away from you? With a hosted provider the honest answer is yes. An automated policy decision can take not just a file but the entire account and everything in it, and the recourse is thin. This is the one that gets people moving.

Control over your data. Can someone read what should not be read? This is a separate question and self-hosting answers it much less completely than people assume. Step 4 is entirely about this, because it is where the reasoning usually goes wrong.

Control over the software. Can the thing you depend on change under you? Not a hypothetical.

The fork is the evidence for the third one

In April 2016, Frank Karlitschek resigned from ownCloud, the project he had founded. His stated reason was not technical. It was governance, in his words: “Who owns the community? Who owns ownCloud itself? And what matters more, short term money or long term responsibility and growth?”

That June he announced Nextcloud, and the majority of ownCloud’s core contributors went with him. Within days, ownCloud Inc.’s US operation shut down entirely after its banks pulled its credit.

An entire self-hosting ecosystem reorganized itself around exactly the question this guide is about, one layer down. Not “is my provider scanning my files” but “who controls the thing I depend on.”

I was running ownCloud at the time, and the honest retrospective is that the case for self-hosting was weaker then than it is now. Home upload bandwidth was worse, the mobile clients were rough, and the reliability gap against a hosted provider was real and daily. What has changed since is less about the software than about the reasons. The software got good enough a while ago. The reasons got much stronger.

The bookend is recent and most comparison content has not caught up to it. ownCloud was acquired by Kiteworks, and in May 2026 Kiteworks stood up a formal Open Source Program Office under the ownCloud brand, retired the legacy Contributor License Agreement in favor of a DCO model, and relicensed Infinite Scale under Apache 2.0. That is a company answering Karlitschek’s governance question directly, ten years later. At the same time, community reports are that ownCloud’s app ecosystem has thinned since the acquisition as community developer interest moved elsewhere. Both halves are true and neither shows up on a feature table.

The lesson generalizes, and it is the one to carry into the rest of this guide: pick for the exit, not the feature list. Every project in this space can change hands, change license, change direction, or stop. The question that survives all of that is what it costs you to leave.

Three Models, and Why the Comparison Lists Are Wrong

Search for self-hosted cloud storage and you get ranked lists. Nextcloud at one, Seafile at three, Syncthing at five, File Browser at eight, scored across a grid of features. The format implies these are substitutes and that the differences are matters of degree.

They are not substitutes. There are three fundamentally different models here, and picking the wrong model is a much more expensive mistake than picking the wrong app within a model.

Server-sync: Nextcloud, ownCloud, Seafile

A server holds the authoritative copy. Clients sync against it. Because there is a server, there is a web interface you can reach from a machine that has nothing installed, share links you can send to people who will never install anything, server-side versioning and trash, and mobile photo autoupload that works the way people expect.

You pay for that with a server: a thing that has to be maintained, patched, backed up, and kept off the public internet or properly defended on it.

Peer-to-peer: Syncthing and its relatives

No server. Devices discover each other and agree on the contents of a folder. It is elegant, it is genuinely private by construction, and for keeping your own machines in agreement it is lighter and lower-maintenance than anything in the previous category.

What you give up is not a feature or two, it is a category:

• No web access. There is no URL to open on a machine that does not run it. The web UI is for configuring the daemon, not for browsing your files.
• No share links. You cannot send a link to someone who does not run Syncthing and is not going to.
• No always-on copy unless you provide one. Two laptops that are never on at the same time never sync. In practice most people end up standing up an always-on node, at which point they have a server again, just one with fewer features.
• Weak mobile photo backup. The Android situation is workable. The iOS situation runs into the platform’s background execution limits, which is a structural constraint rather than a missing feature.

None of that makes it worse. It makes it a different product. Compared as a Google Drive replacement it looks deficient; understood as “keep my own devices in agreement with no server and no cloud,” it is the best thing here.

Web file manager: File Browser

Not sync at all. A web UI over a directory on a machine. Upload, download, rename, browse, share a link.

The honest use is “let me see and grab what is on this box without opening an SSH session.” It is very good at that. It gets installed by people expecting Dropbox, who then conclude that self-hosting is bad, when what actually happened is that they installed a file manager and expected a sync engine.

The question that picks your model

One question does most of the work:

Yes: you need server-sync. That is what share links, a web UI, and server-side permissions are for, and nothing in the other two categories substitutes.

No, it is only ever your own devices: peer-to-peer is lighter, has no server to maintain or breach, and has essentially no lock-in.

Neither, you just want to look at what is on a machine: that is a file manager, and it is a thirty-second install rather than a project.

Pick the model first. The app argument only makes sense inside a model.

Exit Cost Is the Question That Decides It

You are reading this because a provider’s policy turned out to be something you were subject to rather than something you chose. Apply the same test to the replacement. The useful question is not which has more features, it is: if I want out of this one too, what does that cost me?

This is where the real technical difference between these projects lives, and it is almost never what the comparisons focus on.

Nextcloud stores your files as files

Under Nextcloud’s data directory, your files are ordinary files in ordinary directories. You can walk in with rsync, copy everything out, and leave. No export step, no database, no tooling from the project itself.

This is Nextcloud’s single most underrated property and it is not marketed as a feature anywhere, because “we did not invent a storage format” does not sound like an achievement. In a category defined by lock-in it is the most important thing on the list.

One caveat that matters and connects to the next step: this stops being true if you enable server-side encryption. Turn that on and the on-disk files are no longer plain. It is one of several reasons that feature is more often a mistake than a win.

Seafile does not store your files as files

Seafile splits files into blocks, addresses them by content, and keeps a database that maps libraries and versions onto those blocks. The payoff is real and measurable in daily use: identical blocks are stored once, so duplicate content across a library costs nothing, and syncing a change to a large file moves only the changed blocks instead of the whole file. On big files it is genuinely faster than whole-file sync.

The cost is the exit. Your data on disk is a pile of content-addressed blocks and a database. Without Seafile and an intact database, it is not meaningfully recoverable by hand. Your backup strategy has to cover both, consistently, or you have a pile of blocks and no map.

There is a second-order consequence worth knowing before you commit: Community Edition has no automatic garbage collection. Because of deduplication, blocks belonging to deleted files are not removed when you delete the file. They sit in storage until you run garbage collection manually, which is an offline operation. Delete a large amount of data and watch the disk not go down, and this is why.

Seafile is a good piece of software. It is the right pick if fast delta sync on large files is the thing you actually need. Just make the trade knowingly, because it is exactly the kind of dependency you came here to get away from.

The other two

ownCloud Infinite Scale is a ground-up Go microservices rewrite with its own decomposed storage layout, now under Apache 2.0 with formal open-source governance. The governance story is arguably the healthiest it has been in a decade. The community app ecosystem is thinner than Nextcloud’s. It is a legitimate choice; it is just rarely the one that matches why a reader got here.

Syncthing’s exit cost is zero. There is no server format, because there is no server. Every device holds plain files in a plain directory. That is the flip side of everything it cannot do, and it is a real point in its favor.

File Browser’s exit cost is zero for the same reason. It is a viewer over a directory that already existed.

Self-Hosting Is Not Encryption

This is the step that corrects the premise most people arrive with, and it is the difference between a decision that holds up and one that just feels better.

Moving your files onto your own machine stops Google from scanning them. It does not encrypt anything. Those are separate problems and self-hosting only solves the first.

What Nextcloud’s encryption options actually do

Server-side encryption is the one people turn on because it is in the admin panel and sounds like the answer. Its actual properties:

• It encrypts file contents. It does not encrypt filenames or folder structure.
• It does not protect against a compromised server or a malicious administrator, because the keys are present in server memory whenever a user is logged in and can be retrieved by an attacker who has the box.
• Nextcloud’s own documentation is fairly direct that its real benefit is for external storage, meaning storage that belongs to somebody else and that you are treating as untrusted.
• It breaks the walk-away-with-rsync property from Step 3.

So on a server you own, encrypting against a threat model where you own the server, it costs you your exit and buys you very little.

End-to-end encryption is real encryption and carries real costs. It is client-side only by design, which means the web interface cannot decrypt your files at all, sharing an encrypted folder requires key exchange between trusted devices, external sharing gets substantially harder, and collaborative editing is off the table. It protects file contents; it does not cover metadata. It is a deliberate trade, not a checkbox.

The part nobody mentions: whose disk is it

There is a distinction that self-hosting guides collapse constantly. Hardware in your house is a genuinely different claim from a virtual machine you rent. On a rented VPS the provider holds the physical disk, and on most hypervisors can snapshot memory. Self-hosting on rented infrastructure moves who you are trusting; it does not remove the trust.

That is fine, and plenty of things belong on a VPS. It just means “I self-host, therefore nobody can read my files” is not a sentence that follows.

What actually works

Encrypt on your machine, before the file leaves it, independent of where it is going. Then the destination stops being a security decision. Your Nextcloud, your VPS, a friend’s NAS, Google Drive: it does not matter who holds the ciphertext, which is the entire point.

This is the habit that makes tiering in Step 5 work, and it is worth being clear that it is a habit rather than a product. The tool follows the file class:

The finding: filenames leak at every layer

This one is worth internalizing because it is the same mistake repeating across four unrelated tools, and it is off by default in most of them:

• WinRAR: “Encrypt file names” is a separate checkbox in the password dialog. Set a password without ticking it and anyone can list the archive’s full contents without knowing the password.
• 7-Zip: header encryption is likewise a separate option.
• rclone crypt: filename encryption is a configuration setting with multiple modes, including off.
• Nextcloud server-side encryption: does not encrypt filenames at all, as above.

A directory listing is frequently all an adversary needs. Filenames carry surnames, employers, case numbers, dates, diagnoses, account numbers. Encrypting the contents while publishing the index is a very common half-measure.

The interaction with sync, which decides your pairing

A monolithic encrypted container is hostile to file-level sync. One VeraCrypt volume or one large encrypted archive is, to the sync engine, a single enormous file. Change one byte inside it and Nextcloud re-uploads the entire thing, because Nextcloud syncs whole files.

This is one of the few places where Seafile’s block model wins outright: it moves only the changed blocks, so a large encrypted container is far less painful. Which means the encryption shape you choose and the sync engine you chose in Step 3 are not independent decisions.

The practical resolution for most people is per-file encryption rather than one big container, so that only the changed file moves. If you want the single-vault experience anyway, know that you are choosing to re-upload the vault on every change, and size it accordingly.

Tiering in Practice

Here is the actual recommendation, and the reason the migration framing is a trap. Sort by two questions: what happens if this is read, and what happens if this is lost. They produce different answers and most people only ask the second.

Tier 1: never leaves hardware you own, and is encrypted by you regardless. Identity documents, tax and financial records, legal correspondence, medical records, credential exports, and anything containing someone else’s personal information that they gave you in confidence. The defining feature of this tier is that it is small. For most people it is single-digit gigabytes. It is also the only tier where the original worry actually applies with force.

Tier 2: self-hosted, not paranoid. Working documents, project files, notes, configuration, personal photos you would simply rather not have classified by somebody’s model. This is what a Nextcloud is genuinely for: your stuff, on your box, reachable from your phone, without a subscription and without a scanner. Encrypt selectively rather than universally, because encrypting this tier wholesale is what makes people abandon the setup.

Tier 3: leave it where it is. Bulk media, shared albums, anything going to people who will never install a client, anything where availability matters more than privacy. Hosted providers are extremely good at this and self-hosting it is a chore that buys nothing. This is also where the terabytes are.

The single most useful thing about this split is what it does to the size of the problem. Treating all three as one job makes self-hosting look like a four-hundred-gigabyte migration with a capacity bill attached. Separated, the part that actually addresses the concern is small enough to do in an evening.

Where it lands

For Tier 2, the build is already written: Proxmox guide, Step 8. Container with a separate data volume, MariaDB and Redis, a certificate from a local CA so internal names get real HTTPS, and the warnings sweep. Nothing in this guide changes that build.

For Tier 1, the storage does not need to be an application at all. A directory on a machine you own, holding encrypted files, backed up, is sufficient and has the lowest possible exit cost. Adding a sync engine to your most sensitive tier adds attack surface to the tier that least wants it.

File Browser fits here, and it is not a tier. It is the utility you put on a box so you can see and pull files off it from a browser without an SSH session. It belongs on a host you already run, on your internal network or tailnet, and it does not belong on the public internet.

For reaching any of it from outside the house, this guide family’s consistent answer is an overlay network rather than published ports. Files are the easiest case to accept that for, because unlike a webhook endpoint or a client portal, there is no public that needs to reach your files. Names and internal certificates for all of this are covered in the local DNS and reverse proxy guide.

If You Do Want Out Entirely

Some readers will want the full exit anyway, and there is a specific, well-documented place where it goes wrong. It is worth knowing about before you start rather than after.

Drive files are mostly fine. Ordinary files come back as ordinary files. The catch is native Google formats. Docs, Sheets, and Slides do not exist as files; they are exported through a conversion on the way out, and that conversion is lossy for anything with real formatting, embedded objects, or complex spreadsheet features. Check a few important ones by hand rather than assuming.

Photos is where it hurts, and this is the part that surprises people:

• You do not get your originals back. Takeout hands you Google’s processed copies, not the files you uploaded.
• The EXIF timestamp may be wrong in the file itself, because Google’s upload processing can overwrite the original capture date with the upload date.
• The real date and GPS are split out into JSON sidecar files sitting next to the images, rather than embedded in them.
• The sidecar naming is inconsistent. An image may get IMG123.jpg.json, or just IMG123.json, with additional truncation rules that bite long filenames. Any naive matching script gets this wrong on a meaningful fraction of the library.
• Photos edited in Google Photos frequently have no sidecar at all.
• Large libraries arrive as many multi-gigabyte archives with individual files split across archive boundaries. Extracting them one at a time produces corrupt files. Extract the whole set together.

Import that raw into any photo application and the result is predictable and demoralizing: a decade of photos all dated the day you extracted them, sorted into one enormous pile, with the albums gone.

The fix direction is to reconcile the sidecars into the images’ own EXIF before importing anything. exiftool is the standard instrument for this and there are several purpose-built wrappers around it. The discipline that matters more than the tool choice:

• Work on a copy, never in place on your only extraction.
• Handle the missing-sidecar and inconsistent-naming cases explicitly rather than letting them fail silently, because silent failure here looks exactly like success until months later.
• Spot-check a sample by hand against dates you actually know before you trust the run.
• Do not delete the Google side until the imported library has been verified and backed up. Holding two copies during a migration is not paranoia, it is the migration.

What This Guide Deliberately Leaves Out

• Immich and dedicated photo libraries. Photo management is a different problem from file sync, with its own indexing, face recognition, and mobile backup concerns. It deserves its own treatment rather than a paragraph here.
• Object storage backends. Running Nextcloud with S3 or R2 as primary storage rather than a local disk changes the exit-cost analysis in Step 3 considerably, and is its own topic.
• Multi-user and family setups. Everything above assumes one person’s files. Quotas, groups, and shared spaces are a real layer that this does not address.
• Federation. Nextcloud and ownCloud can share between instances. Interesting, and not what anyone arrives here asking about.

On provenance: Steps 1 through 5 come from a Nextcloud running in production on the Proxmox build linked above, from ownCloud use that predates the 2016 fork, and from a long-standing habit of encrypting before upload regardless of destination. Step 6 is researched rather than run, and says so. The ownCloud and Seafile positions in Steps 2 and 3 are structural comparisons drawn from their documentation and licensing, not from running either at current versions.