How to replace Google Drive with a Nextcloud server you own

Cloud storage is the most intimate thing most people hand to a company. Not the documents — the photos, the scans of identity papers, the tax returns, the backup of a phone that has everything on it. It sits in an account that can be suspended by an automated system with no appeal, on servers that scan what you upload, tied to an identity you verified years ago and cannot detach. People discover the shape of that arrangement at the worst possible moment, usually when a locked account takes twenty years of family photos with it. Nextcloud is the open-source answer: the same sync clients, the same phone app, the same shared links — running on a machine you rent, holding files nobody else indexes. Installing it takes an afternoon. What decides whether it is actually better than what you left is the disk underneath, and an encryption question almost every tutorial gets wrong.

What Nextcloud actually replaces

Nextcloud is not a single app so much as a small suite that happens to cover most of what a consumer cloud account does. That breadth is the reason it is worth self-hosting at all: replacing one service with a self-hosted equivalent is rarely worth the maintenance, but replacing five of them with one server usually is.

• File sync and sharing, which is the core. Desktop clients for Windows, macOS and Linux, mobile apps for both platforms, and a web interface — the same drag-a-folder-and-it-appears-everywhere behaviour you already expect.
• Photo backup from your phone, with automatic camera upload, albums and face grouping. For most people this is the single largest chunk of data and the reason the disk needs sizing properly.
• Calendar and contacts over the open CalDAV and CardDAV standards, which every phone speaks natively — no third-party app required to sync them.
• Collaborative documents through an office suite you can add on, editing spreadsheets and text files in the browser without sending them anywhere else.
• Public share links with passwords, expiry dates and upload-only drop folders, which is the feature that usually ends the habit of emailing large attachments.
• Server-side versioning and a trash bin, so an overwritten file or a bad sync is recoverable without going to a backup.

The boundary is worth stating plainly, because the marketing around self-hosting rarely does. Nextcloud gives you control and privacy. It does not give you the durability of a hyperscaler — those companies replicate your data across continents, and a single rented server does not, no matter how good its disks are. It also does not make the files free: you are paying for storage either way, just to a host that never asked your name instead of one that did. Self-hosting is a trade of somebody else's reliability for your own control, and it is a good trade only if you take the reliability half seriously.

You become the storage provider

That is the honest cost, and it is much better understood before the migration than after. Nobody watches your uptime, nobody has a copy of your photos, and nobody is on the other end of a support line at the moment a sync client reports a conflict on a file you needed this morning.

• Backups are yours, and they are not optional. A RAID array survives a dead disk; it does not survive a deleted folder, a bad upgrade or a ransomware run through a synced directory. Versioning and the trash bin are convenience features, not a backup.
• Uptime is yours. A sync client that cannot reach the server queues changes quietly and catches up later, which is forgiving — but a share link you sent a client is dead while the box is down.
• Updates are yours, and Nextcloud ships them briskly. It is a PHP application on a public IP with your entire life in it, so patching is not something to defer for a quiet month.
• Capacity is yours to watch. A phone that uploads every photo automatically will fill a disk you sized generously, on a timeline you did not plan, and a full disk corrupts more than it stops.
• Recovery is yours. Restoring means the database and the file tree together, at a matching point in time. Restoring one without the other produces a working interface listing files that are not there.

None of that is heavy once it is set up. It is a few minutes a month plus one careful afternoon at the start, and it is the same discipline any self-hosted service needs — the difference is only that this one holds the things you would most hate to lose. If you have already worked through hosting a website yourself, none of it will be unfamiliar.

Sizing the machine: budget for the data, not the application

Nextcloud itself is a modest PHP application. Nearly every sizing mistake here comes from pricing the application and forgetting that the point of the exercise is to hold data that grows. Get the shape right at the start, because migrating a file tree and its database between machines later is the least pleasant afternoon in self-hosting.

• Storage is the decision that picks your plan, and you need roughly double what your files measure today. Versioning keeps old copies of changed files, the trash bin holds deletions for a retention window, and generated thumbnails and previews are a real percentage on top of a photo library.
• Memory decides how it feels rather than whether it works. 2 GB runs a single-user instance; 4 GB is comfortable for a household with phone uploads running; 8 GB and up matters when a document suite and a handful of simultaneous users are in play.
• CPU is idle almost all the time, then briefly matters a great deal — the first pass of preview generation over an imported photo library, and any on-the-fly document conversion, are the spikes worth having headroom for.
• The database wants fast storage and the files do not, particularly. Metadata operations hit the database constantly while the file tree is mostly sequential reads and writes, which is why a small NVMe root disk alongside bulk capacity is a better shape than one giant slow volume.
• Transfer is unmetered here, but the initial upload of an existing library is a genuinely large one-off. Plan for it to run overnight rather than being surprised by it.

In practice, that lands in two places depending on how much you are actually storing. Under a few hundred gigabytes — documents, a modest photo library, one or two people — VPS-8 at $13.99/mo with 4 vCPU EPYC, 8 GB DDR5 ECC and 120 GB of Gen4 NVMe is fast and more than enough. Once a phone with a camera roll is in the picture, capacity becomes the whole question and NVMe is the wrong thing to be paying for: a storage server from $7.99/mo gives you 1 TB on RAID-6, and STO-4 at $22.99/mo gives you 4 TB — which is a different category of headroom from any VPS, at a fraction of the price per terabyte. If you are consolidating a household or a small team past that, a dedicated server from $64/mo with 2 × 1 TB NVMe gives you both speed and space without the arithmetic getting silly.

Step by step: from a fresh server to a working sync

1. 01Deploy the server and harden it firstA Debian or Ubuntu box, keys-only SSH, default-deny firewall — before a single file is on it. Do this while the machine is still empty and boring.
2. 02Point a domain at it and let a certificate issueNextcloud clients will refuse to sync over plain HTTP, and rightly so. The hostname must resolve to the machine before the certificate can be issued, which is the most common failed install by a wide margin.
3. 03Choose your install method and commit to itThe container image is the fastest route and the easiest to keep updated; a manual install on a web server and database gives you more control over tuning. Pick one — mixing the two is how upgrades break.
4. 04Use a real database, not SQLiteSQLite works for exactly one user doing nothing much, and it falls over the moment two clients sync at once. Choose MariaDB or PostgreSQL at install time, because converting afterwards is an unpleasant migration.
5. 05Add a memory cache and configure background jobsRedis for locking and caching, and a system-level cron for background jobs rather than the browser-triggered default. Skipping these is why some self-hosted instances feel sluggish and others feel instant.
6. 06Raise the upload limits before you migrate anythingThe defaults are sized for small files and will reject a video or a disk image. Fix the limits in the web server and PHP configuration first, or your first big upload fails at ninety percent.
7. 07Migrate your files in one deliberate passUpload the existing library from a desktop client or copy it into place and trigger a scan. Do this once, overnight, before anyone is depending on the instance.
8. 08Connect the clients, then set up backups the same dayDesktop sync, phone auto-upload, calendar and contacts. Then configure and actually test the backup — an instance in production without a restore path is a countdown.

Encryption: what actually protects you, and what only sounds like it does

This is the section that matters most if you moved off a consumer cloud specifically because a company could read your files, and it is the one most guides get wrong. Nextcloud has a feature called server-side encryption. Turning it on feels like the answer. It mostly is not, and understanding why saves you from a false sense of safety that is worse than no encryption at all.

• Server-side encryption keeps the keys on the server. The application must be able to decrypt your files to serve them to you, so anyone with access to the running machine has everything the machine has. It protects against a stolen disk or an untrusted external storage backend — not against a compromised server or its operator.
• End-to-end encryption is the real thing, and it is deliberately limited. It encrypts on the client for specific folders, which means the server genuinely cannot read them — and equally means no web interface, no previews, no server-side search and no public share links for that content.
• Full-disk encryption on the server protects a powered-off machine. A running server has the volume mounted and the key in memory, so it defends against disposal and physical seizure of a cold box, and nothing else.
• Encrypting before upload is what most people actually want. A tool that encrypts a folder locally and syncs the ciphertext gives you real confidentiality with a normal Nextcloud underneath, at the cost of previews and browser access for that folder.
• Transport encryption is not storage encryption. HTTPS protects files in flight and nothing at rest, and conflating the two is the most common misunderstanding in this whole area.

For most people the honest answer is a mixed one. Run the instance normally — it is your server, and the convenience of previews, search and share links is the entire reason you are not just using an encrypted archive. Then take the genuinely sensitive minority of your files, the papers and the keys and the things that would matter in a bad year, and encrypt those client-side before they ever reach the disk. That gives you a usable cloud and a real vault, instead of one mediocre compromise pretending to be both.

The identity leaks a default install leaves in place

Nextcloud removes the company that was reading your files. It does not, on its own, remove everything that ties the server to a person — and most of those come from steps that feel unrelated to storage.

• The domain. A registrar holds your identity even when public WHOIS is redacted, and it needs a working contact address to keep the name alive. The hostname is the most common way a self-hosted service is traced back to its owner.
• Certificate transparency. The moment a certificate is issued, the exact hostname is published in public logs anyone can search. A subdomain you assumed was private — cloud.something, files.something — is announced worldwide with a timestamp on it.
• The host. If the server was rented with a card in your legal name, the machine is in your legal name regardless of what runs on it. That is settled at signup, long before the first file.
• Mobile push notifications. The official apps route notifications through the platform vendors' push services by default, which means metadata about your instance reaches Google or Apple even though your files do not.
• Photo metadata. Images carry EXIF data including GPS coordinates and device identifiers. Moving a camera roll to your own server does not strip any of it — it just moves it somewhere you control, which is better but is not the same as removing it.
• External integrations. Federated sharing, remote storage backends, mail notifications and app-store update checks all reach out from the machine, and each one is a third party that sees your server.
• Server logs. Your own logs record IP addresses and user agents for every sync. On your own machine that is fine — until the machine is seized, at which point your logs are evidence about your own movements.

Closing those is ordinary work rather than anything exotic. Pick a registrar that accepts crypto and collects the minimum. Put the machine on a host that never asked who you are and pay from a crypto balance — Bitcoin is pseudonymous rather than anonymous, so topping up in Monero is what closes the on-chain trail if that matters to you. Turn off push notifications if the metadata bothers you and accept the delayed sync that follows. And if the instance is only ever for you and a couple of trusted people, do not expose it to the whole internet at all: put it behind a WireGuard tunnel and let it answer only on the tunnel — which also removes the entire category of attacks against a public login page.

Keeping it alive after the migration

A file server that has worked for a year is a file server nobody has looked at for a year. A short routine is the difference between that and losing the thing you built it to protect.

• Back up the database and the file tree together, from a consistent point in time. A file backup without its matching database restores as an empty-looking instance full of orphans.
• Keep a copy that is not on the server. A snapshot living on the same machine survives a disk failure and nothing else — not a compromise, not a mistaken deletion that syncs everywhere, not a lost account.
• Restore once, deliberately, while nothing is wrong. An untested backup of your photo library is a hypothesis about your memories.
• Update on the project's cadence and never skip a major version. Nextcloud upgrades one major release at a time, and jumping two is a migration you will have to unpick by hand.
• Watch free space with real headroom. Upgrades need room to work, and a disk that fills during a database migration is how a routine update becomes a restore.
• Check that background jobs are actually running. Preview generation, trash cleanup and version pruning all live there, and a silently broken cron shows up months later as a mysteriously full disk.

Add an external check while you are at it — something that fetches the login page from outside and complains when it stops answering tells you the instance is down before a queued sync client does. And treat the machine itself the way the first ten minutes on a new VPS describes, because the stakes on a box holding every document you own are not lower than on one holding money.

Mistakes that cost people their files

• Installing on SQLite because it was the default, then watching it lock up the first time two devices sync simultaneously.
• Treating the trash bin and file versions as a backup, and discovering they are not on the day a sync client propagates a deletion everywhere.
• Migrating the entire photo library before configuring backups, and living for a month in the window where the only copy is on a rented machine.
• Turning on server-side encryption, concluding the files are now private from the host, and acting on that belief.
• Sizing the disk for what the files measure today, with no allowance for versions, trash and previews.
• Skipping the memory cache and background-job setup, then blaming the hardware for an instance that feels slow.
• Leaving the upload limits at their defaults and finding out mid-migration that anything large silently fails.
• Jumping two major versions in one upgrade because the instance sat untouched for a year.
• Renting the server and registering the domain in your own name, after doing everything else right.

Nextcloud is one of the rare self-hosted projects that genuinely matches the commercial product it replaces on the things that matter day to day — the sync just works, the phone app just works, and after a week you stop noticing the difference. The install is an afternoon and the migration is a night. What you are left with is every file you own on a machine that answers to you, paid for from a crypto balance, on a host that never asked for your name. Size the disk for what the data will become rather than what it is, encrypt the small part that truly needs it on the client side, and set up the backup before you need it rather than after.