Self-hosted Nextcloud on a VPS: replacing Google Drive with a server you control

What you are actually replacing, and what you are not

Nextcloud is, stripped of its marketing, a PHP application that keeps a database of file metadata and a directory of file contents, and speaks enough protocols that ordinary devices treat it as a normal cloud account. That description undersells how much of your digital life it quietly covers. The file sync is the visible part, and it is the part people install it for. The parts that turn out to matter six months later are the ones nobody demonstrates: calendars and contacts over CalDAV and CardDAV, so your phone's built-in apps stop talking to a mail provider; a photo library with automatic camera upload, which is what actually gets a household off Google Photos; and notes, tasks and bookmarks that are no longer scattered across four accounts you do not control.

It is worth being precise about the comparison, because the usual framing is wrong. Nobody self-hosts to save money on gigabytes — a consumer plan with two terabytes costs about what a mid-tier VPS costs and comes with no work at all. You self-host because the alternative is a relationship in which the counterparty holds the data, sets the terms, scans the contents for policy compliance, and processes legal demands about you without any obligation to tell you first. Removing that counterparty is the entire product. Everything else is a side effect, some of it pleasant and some of it your new responsibility.

What you do not get, and should not expect, is the invisible operational floor that a hyperscaler provides for free. There is no multi-region replication unless you build it. There is no edge network making a large download fast from the other side of the planet. There is no support queue that finds your file when you delete it and empty the trash on the same afternoon. When the disk fills at three in the morning, the sync clients on five devices will start showing red icons, and the person who fixes that is you. This is not an argument against doing it — it is the specification of the job you are accepting.

The last thing to be clear-eyed about is the update cadence. Nextcloud releases major versions several times a year, upgrades must be applied one major version at a time, and third-party apps you have come to depend on sometimes lag a release behind. This is not difficult work, and the built-in updater plus a snapshot beforehand makes it a fifteen-minute job, but it is recurring work with a deadline attached: an instance three majors behind is an instance you cannot upgrade in one step and cannot safely expose to the internet either.

The machine: sizing for a file server, not for a website

Most self-hosting guides size a server by its application. For this one the application is almost irrelevant and the library is everything. The PHP process, the web server, the database and the cache together fit comfortably in a gigabyte or two of RAM under household load; what decides your plan is how many bytes you are putting on the disk and how many individual files those bytes are divided into, which are two separate constraints that fail in two different ways.

Start with the honest inventory rather than the aspirational one. Documents and spreadsheets are noise — a decade of them rarely passes ten gigabytes. The camera roll is not noise: a modern phone produces somewhere between fifteen and forty gigabytes a year per person once video is included, and switching on automatic upload for a family of four is a commitment to roughly a hundred gigabytes annually that arrives whether you think about it or not. Then add overhead on top of the raw library: generated previews for images and video, file versions kept for edited documents, and a trash bin that by default holds deleted files for up to thirty days and counts against the same disk. A working figure of the library plus twenty per cent is realistic, and the twenty per cent is the part people forget until the disk is at ninety-five.

Memory is the second constraint and it is much cheaper to satisfy. Four gigabytes runs a single-user instance without drama. Eight is the comfortable number for a household or a small team, because it lets you give PHP-FPM enough workers to absorb several sync clients waking up at once, hand the database a real buffer pool, and still have room for the operating system's page cache to keep the hot metadata in memory. The number changes materially only if you add Nextcloud Office, which runs a full document-conversion engine in its own container and wants two to four gigabytes to itself before anybody opens a spreadsheet.

CPU barely registers in steady state and then matters intensely for about a week. Generating previews for an existing photo library is the heaviest thing this server will do — every image is decoded and re-encoded at several sizes — and on a small plan that initial pass can run for days. Afterwards, serving files is nearly free: the work is I/O, and the sync protocol's chattiness costs more in round trips than in cycles. Buy cores for the import, not for the running instance, and if the import is the only reason you would size up, run it on a bigger plan for a month and come back down. Monthly billing without a contract is exactly what makes that manoeuvre cheap.

That last row is the one worth reading twice, because it is where people get the shape of the machine wrong. A VPS is excellent at being a sync-and-share hub for the working set a group of humans touches. It is a poor container for a media archive: the largest tier we sell tops out at six hundred and forty gigabytes of local NVMe, and once your library is measured in terabytes the right answer is dedicated hardware, where a mirrored pair of drives gives you one or two terabytes with redundancy underneath. Deciding that before you start is far less painful than moving a populated instance after you have run out of room.

The database decision you make once

The installer will offer you SQLite and it will work. Use it for a demonstration you intend to delete, and for nothing else. SQLite serialises writes across the whole database, and this application writes constantly — every sync client poll, every scanned file, every activity entry — so the moment two clients are active the requests queue behind one another and the interface acquires a lag that no amount of tuning removes. The official requirements say as much, politely.

MariaDB and PostgreSQL are both first-class and the choice between them is close to preference. MariaDB is what most deployments run and what most community answers assume, which is worth something when you are searching an error message at midnight; it needs the database created with the four-byte UTF-8 character set so that emoji in filenames do not truncate a row, and it wants its transaction isolation set to read-committed, which the documentation states plainly and which people skip. PostgreSQL is quietly better under concurrency and needs less coaxing, at the cost of a slightly smaller pool of copy-and-paste answers. Either is correct; running whichever you already know how to back up is more correct than either.

Put it on the same machine and connect over a unix socket. This is one of the few places where the obvious architecture is also the right one: a single instance gains nothing from a database on another host and loses a network round trip on every one of the many small queries the application makes. Bind the database to the loopback interface, never to the public one — the hardening checklist covers why a listening database is the single most common way a small server is taken away from its owner.

The thing to understand about this database is that it is small in bytes and enormous in consequence. Its central table holds one row per file per user — a hundred thousand files across four accounts is a few hundred thousand rows, which is nothing for a modern engine, and a few hundred megabytes on disk. But that table is the only thing that knows the structure of your data. Lose the database and keep the files and you have a directory tree with no shares, no versions, no comments, no tags and no sync state. The command-line rescan will rebuild a usable tree out of that, which is a genuine relief the first time you need it, and it will not bring back a single share link or version history. Back the two up together, always, and treat a backup of one without the other as no backup at all.

Why the default install feels slow — and the four settings that fix it

A freshly installed instance is usually described as sluggish, and the people describing it are not wrong. It is not the hardware and it is not PHP: it is four stock settings that are chosen for maximum compatibility on shared hosting rather than for a machine you control. Changing them takes twenty minutes and produces the single largest perceived improvement anyone will ever make to this installation.

The first is background jobs. Out of the box these run in AJAX mode, which means the queue only advances when a human loads a page in a browser — so previews are not generated, trash is not expired, federated shares are not refreshed and search indices are not built until somebody happens to visit. Switch to a system cron entry running the job runner every five minutes as the web-server user, exactly as the background jobs documentation describes. Half of the mysterious it-does-not-do-anything complaints about Nextcloud are this setting.

The second is caching and file locking. Without a shared cache the application re-reads configuration and app metadata constantly, and without transactional file locking backed by Redis it falls back to locking rows in the database, which is precisely where you do not want contention. Install Redis, have it listen on a unix socket rather than a TCP port so nothing on the network can reach it, and point both the distributed cache and the file-locking backend at it while leaving the fast local cache on APCu. The caching configuration reference gives the exact block.

The third is the PHP opcode cache. The stock buffer sizes were sized for a small application and this is not one — the administration overview will tell you outright that the interned-strings buffer is nearly full, and a full buffer means the interpreter is doing avoidable work on every request. Raising opcache memory and the interned-strings buffer, and lifting the maximum accelerated files well above the default, costs a couple of hundred megabytes of RAM and is felt immediately on every page load. The fourth is PHP-FPM's process manager: the default child count is tuned for a machine with far less memory than yours, and a household with several sync clients will queue behind it. Size the worker count against your actual RAM and the per-worker footprint, which is the one calculation in this section worth doing on paper.

One related trap deserves its own paragraph because it produces a confusing symptom. Uploading a large file through the web interface fails, while the same file uploads fine from the desktop client. That is not a bug: the desktop client splits uploads into chunks and reassembles them server-side, so it slips under every limit, while the browser sends one large request that must survive PHP's upload and post size limits, the web server's own maximum body size, and any timeout in between. If the browser is where large files enter your instance, all of those numbers have to be raised together — raising one and not the others simply moves which component says no.

Three different things are called encryption, and they protect against three different people

This is the section where most self-hosted deployments go wrong, and they go wrong in an understandable way: three unrelated features share a word, the administration interface offers all of them, and enabling more sounds safer than enabling fewer. It is not. Each one defends against a specific adversary, each one costs something, and one of the three is actively harmful when applied to the case people usually apply it to.

Full-disk encryption is the layer underneath everything. It protects data on a powered-off machine — a disk pulled from a rack, a decommissioned drive, an image copied from cold storage. It does nothing whatsoever while the server is running, because the volume is unlocked and the operating system reads it as ordinary files. It is cheap, it is invisible, it has no effect on any Nextcloud feature, and there is no good reason not to have it. What it demands is a remote-unlock plan, because a server that reboots at four in the morning stays down until somebody types a passphrase; the full-disk encryption guide covers the initramfs SSH arrangement that makes that survivable.

Server-side encryption is the one to think hardest about. It encrypts file contents with keys that live on the same server, managed by the same application, and its actual design purpose is protecting data you place on storage belonging to somebody else — an object store, a rented external mount, a third-party backend. Applied to local primary storage on a machine you already control, it protects you from very little, since anyone who can read the files can read the keys; and it costs you roughly a third more storage, complicates every recovery scenario, and disables features that need to read file contents. The encryption documentation is unusually direct about the trade-off. If your storage is local NVMe on a server you rent alone, leave it off and use the disk layer instead.

End-to-end encryption is the real thing, and it is the only one of the three that protects you from the server. Files in an end-to-end folder are encrypted by the client before they leave the device, and the server stores ciphertext it cannot open — which is exactly what you want for the small subset of material where compelling the host must not produce readable data. The price is severe and non-negotiable: those folders have no web interface, no server-side search, no thumbnails, no public sharing, and no recovery if you lose the mnemonic that unlocks them. That is not a limitation to engineer around, it is the definition of the guarantee. Use it for the folder that genuinely needs it and leave the family photo library outside, where previews work and life is pleasant.

The clients, and the parts other people actually touch

Whether this project succeeds is decided almost entirely by people who will never log into the server, and their verdict is formed in the first week by three pieces of software. The desktop client is the one that matters most. Configure it with virtual files rather than a full local copy — files appear in the file manager, occupy no space until opened, and download on demand — because that is what makes a two-hundred-gigabyte library usable on a laptop with a small disk, and it is the behaviour people already expect from the commercial clients.

The mobile app carries the feature that converts sceptics: automatic upload of the camera roll. Turn it on for the people in your household, point it at a per-user folder, and within a month the argument about leaving Google Photos is over. It is also, and for exactly the same reason, the thing that will fill your disk on a schedule you did not choose, which is why the sizing section above spends its time on cameras rather than documents. Set a quota per user from the beginning — not because you intend to enforce it, but because a quota turns silently running out of disk into a clear message on somebody's phone.

Calendars and contacts are the quiet win and the most common thing left half-configured. Nextcloud speaks CalDAV and CardDAV, which every phone and desktop supports natively, so nobody needs a new app — but discovery relies on a pair of redirects at /.well-known/caldav and /.well-known/carddav that live in your web-server configuration rather than in the application. Get them wrong and account setup fails with an unhelpful error on iOS while working fine on Android. The administration overview flags this explicitly, which is one more reason to clear that page before anybody else arrives.

Two smaller notes save real time. WebDAV mounting is supported and is genuinely convenient for occasional access from a machine you do not want to install anything on; it is also slow, because every operation is an HTTP round trip, so it is a bad choice for a working directory and a fine one for grabbing a file. And create an application password for every device instead of handing out the account password: revoking a lost phone then means deleting one token rather than changing a password and re-authenticating every other client you own. Pair that with two-factor authentication on the accounts, and keep an administrator account that nobody uses day to day separate from the account you actually sync with.

Where the jurisdiction stops being an abstraction

For most things you might self-host, the location of the machine is a latency decision with a legal footnote. For your entire document archive, your photographs, your contacts and your calendar, the priority inverts — this is the single machine where the legal question outranks the network one, because the data on it is the sort that legal process is actually issued for.

Understand what changes when you move off a hyperscaler. When your files live with a large provider, a demand for them is served on that provider, evaluated by its legal department against its own interests, and complied with under a gag order more often than not — you may never learn it happened. When the files live on a server you rent, there is no such department and no such reflex, and the demand has to find somebody. That is not a magic shield; it is a structural change in who gets asked, how visible the asking is, and how much friction stands between a request and a copy of your data. Our legal explainer works through what that friction is and is not.

Two practical consequences follow. The first is that jurisdiction should be chosen on purpose rather than by latency reflex — the jurisdiction comparison and the note on the 14-Eyes arrangement lay out how the four locations differ, and for a personal archive the answer is usually the strongest legal floor you can tolerate the round-trip time to. The second is that the host can only ever be compelled to produce what the host can reach, which is why the encryption layers above are not decoration: full-disk encryption plus end-to-end encryption on the folders that need it means the honest answer to a demand is a disk image of ciphertext.

There is a latency trade-off and it is smaller than people fear. Sync is a background process — nobody watches a photo upload — so a hundred milliseconds of extra round-trip costs you nothing perceptible on the thing you do all day. Where it shows is opening a document in the web editor or scrolling a large gallery, which is interactive and where the same hundred milliseconds is felt on every action. If the humans are in Europe, Amsterdam or Zürich keeps both experiences quick; if the legal posture is the entire point, Reykjavík costs you a noticeable but tolerable amount of interactive responsiveness and nothing at all on sync.

One obligation is worth stating plainly, because self-hosting quietly transfers it to you. The moment other people's files are on your server — a family member's photographs, a colleague's documents, a client's contracts — you have become the party responsible for them, and in Europe that responsibility has a name and a set of duties attached. It is not onerous at household scale and it is not something to discover during an argument: decide who has access to what, tell the people whose data it is where it lives, and keep the administrator account out of everyday use so that reading somebody else's folder is a deliberate act rather than an accident.

Backups, and the restore you have to rehearse

There are exactly three things to preserve and all three must come from the same moment in time: the data directory holding file contents, the database holding every piece of metadata about them, and config.php, which contains the instance identifier, the database credentials and — if you enabled server-side encryption — the values without which the rest is unreadable. Copy two out of three and you have an interesting archaeological exercise rather than a restore.

Consistency is the part that is easy to get subtly wrong. A file copied while the database is being written produces a backup whose two halves disagree, and the disagreement surfaces weeks later as files that exist on disk but not in the interface, or entries in the interface that point at nothing. The straightforward fix is to put the instance into maintenance mode, dump the database, capture the data directory, and turn maintenance mode off — which is a short outage nobody notices at four in the morning. The backup documentation spells out the sequence, and a filesystem snapshot taken while the application is quiesced achieves the same thing in less time if your storage supports one.

Then send it somewhere else, encrypted before it leaves. Restic or Borg both encrypt client-side and deduplicate well against a data set that changes at the edges, which is the shape of a file server. Make the remote repository append-only so a compromised host cannot delete its own history — that is what turns a backup into a defence against ransomware rather than merely against a failed disk — and put the far end in a different jurisdiction from the near end, since a copy that can be seized in the same action as the original is not really a second copy. Keep the repository passphrase somewhere that is not the server.

The two features people mistake for backups deserve naming. File versions and the trash bin are conveniences that live inside the same instance, on the same disk, in the same database; they recover an accidental overwrite beautifully and survive absolutely nothing that happens to the server. Likewise, hourly provider snapshots — which every plan here includes with seven-day retention — are excellent for undoing a bad upgrade and are not an off-site backup, because they share the fate of the infrastructure they sit on. Use all three. Rely on the one that is somewhere else.

Finally, rehearse the restore, once, while nothing is wrong. Provision a throwaway server, restore the database and the data directory into it, correct the trusted-domain entry in config.php, and log in. You will discover something — a missing PHP module, a database user you never wrote down, an encryption key that lived somewhere you forgot — and you will discover it on an afternoon when it costs you an hour instead of on the day it costs you the archive. If the restore also needs a file rescan to reconcile the tree, that is what the command-line tool is for, and knowing that in advance is the entire point of the exercise.

Sharing outward without leaking inward

The feature that makes this genuinely useful to other people is also the one that puts a URL to your files on the public internet, so it is worth five minutes of deliberate configuration rather than the defaults. Public links should carry a password and an expiry as a matter of policy rather than as a per-link decision — both can be enforced instance-wide, which means the setting is made once by you instead of forgotten every time by somebody else. Upload-only drop folders are the underrated case: a link that accepts files without revealing what is already in the folder replaces every awkward email attachment workflow you currently have.

Behind a reverse proxy — which is how nearly everybody runs this — one configuration value causes a disproportionate amount of confusion. If the application is not told which addresses to trust as proxies, every request appears to originate from the proxy itself. Rate limiting then counts the whole world as one visitor, the brute-force protection eventually throttles that single address, and the effect is an instance that mysteriously slows down or locks out legitimate users while the logs show one IP doing everything. Setting the trusted-proxy list and the protocol override, as the reverse proxy documentation describes, fixes the logs and the protection in one line each.

The trusted-domains list is the other value worth understanding rather than copying. It is an allow-list of hostnames the instance will answer on, and it exists because the application builds absolute URLs — password reset links, share links, federation callbacks — from the host header it receives. Left open, that is a well-known way to have your own links point somewhere else. Add the hostnames you actually use, including the onion address if you publish one, and nothing else.

If some of this should not be reachable from the open internet at all, do not solve that with a firewall rule and a hope. Two clean answers exist: put the instance behind a WireGuard tunnel so it is only reachable from devices holding a key, which works well for a personal archive and badly for sharing with outsiders; or publish it as an onion service alongside the clearnet hostname, which keeps the sync clients working over Tor without exposing an address at all. Both are additive — you can run either alongside a normal public hostname and let the sensitive material live behind the private path.

When you should not self-host this

A guide that never says this is selling something, so here is the list. If the data belongs to a business whose operations stop when the file server does, you are underwriting an availability guarantee with one machine and one person's attention, and a single VPS is not the right instrument for that. High availability for this application is genuinely involved — shared storage, a replicated database, a load balancer that understands sticky sessions — and if you need it, you need a budget and a second person, not a bigger plan.

If nobody will do the monthly maintenance, do not start. The work is small — apply updates, glance at the administration overview, confirm the backup ran, upgrade one major version at a time when a new one lands — but it is unforgiving of being skipped for a year. An instance several major versions behind cannot be upgraded in a single step and should not be facing the internet in the meantime, and the escape from that position is more work than the maintenance would have been.

If your library is measured in terabytes and growing, the shape is wrong rather than the size. No VPS tier we sell reaches a terabyte of local NVMe, and bolting object storage onto the back of the instance moves the problem instead of solving it: the database becomes even more critical, latency on every file operation goes up, and you have quietly reintroduced a third party into a design whose entire purpose was removing one. Buy dedicated hardware with mirrored drives, or accept that the archive and the sync hub are two different systems.

And if what you actually want is Google Docs — thirty people typing in the same spreadsheet with sub-second cursors — be honest that the self-hosted office stack is good rather than equivalent, and that it wants its own memory and its own CPU. Run it because you want the documents on your own disk, not because you expect the collaboration to feel identical.

For everyone else — a household tired of paying rent on its own photographs, a small team that would rather not have its contracts indexed by a company with a policy department, an individual who simply wants the files to be in a place they chose — this is one of the most rewarding things you can put on a server. The software is mature, the clients are good, the failure modes are documented, and the only genuinely unforgiving one is the backup that was never tested. A server takes about a minute to provision, the previews will still be generating while you finish setting up the phones, and you can pay for it with the same privacy posture you are buying it for.