OwnCloud Infinite Scale and the Rewrite Question

In 2000, Joel Spolsky wrote that rewriting your codebase from scratch is the single worst strategic mistake a software company can make. His example was Netscape, which spent three years rebuilding its browser while Internet Explorer ate the web. The essay has been cited approximately four million times since, usually by whoever wants to win an argument about a refactor.

ownCloud did it anyway. Infinite Scale — oCIS — is a from-scratch rewrite of the ownCloud server in Go, abandoning the PHP codebase that had run since 2010. It’s been in the world long enough now that we can stop speculating and look at the results, which is much more interesting than the theory. I’ve had oCIS on a spare machine on and off since the 5.x days, and the honest summary is that the rewrite worked on its own terms and lost on almost everybody else’s.

This matters beyond ownCloud. Every homelabber eventually stands in front of something crusty and asks whether to patch it or burn it down — I’ve written about that decision in the small at technical debt in a home lab. oCIS is the same decision at industrial scale, with receipts.

What oCIS actually is

Start with the thing that surprises people: oCIS ships as one static Go binary. No PHP-FPM. No Apache. No MariaDB. No Redis. You download a file, you run it, and it starts.

1
2
3
4
5
6

curl -L -o ocis https://download.owncloud.com/ocis/ocis/stable/ocis-linux-amd64
chmod +x ocis
export OCIS_URL=https://cloud.example.com
export OCIS_INSECURE=false
./ocis init          # writes ocis.yaml, prints the generated admin password
./ocis server

Three commands and you have a working file-sync server. Anyone who has assembled a classic ownCloud or Nextcloud stack by hand — PHP version dance, opcache settings, a database you have to tune, Redis for locking, a cron user, a reverse proxy — will feel something on reading that. It’s the single most persuasive thing about the project.

Under the bonnet it’s less simple than the binary implies. That one process is a supervisor running roughly two dozen internal services: a gateway, a proxy, an auth service, a users service, a groups service, a storage service, a search indexer, a thumbnailer, an antivirus hook, a notifications service, and so on. They talk over an internal message bus, and any of them can be broken out into its own process when you want to scale a piece independently. The “infinite scale” name is about that: the same code runs as a single binary on a NUC and as a fleet of pods in a cluster.

The storage layer is where the rewrite’s real thesis lives. Classic ownCloud kept file metadata in a SQL database — the notorious oc_filecache table — and the filesystem held the bytes. Every scan, every share check, every sync client poll hit that table. At scale it was the bottleneck, and the operational war stories about oc_filecache corruption are legendary.

oCIS deletes the database. Its default storage driver keeps metadata on the filesystem itself, in extended attributes and a tree of node directories, with blobs stored alongside or pushed to S3. No SQL, no cache invalidation, no files:scan. If you’ve been running MinIO at home, oCIS will talk to it directly as a blob backend, which is a genuinely elegant arrangement.

The API layer is CS3, the shared interface developed with the research-computing crowd (CERN’s CERNBox runs on the same Reva foundation). That’s an unusual pedigree for self-hosted file sync and it explains a lot about the priorities — federated, multi-petabyte, institutional.

And the user-facing model changed too. Classic ownCloud gave everyone a home folder. oCIS gives you Spaces: named containers with their own membership and quota, of which your personal space is merely one. It’s a better abstraction for teams, and it’s a mild irritation for one person with a laptop who wanted a folder.

What the rewrite genuinely bought

Deployment simplicity that borders on rude. Compare the three commands above with what it takes to stand up Nextcloud properly. Even the all-in-one appliance route, which I picked apart in Nextcloud AIO: worth it or not, is a mastercontainer orchestrating eight containers and demanding a Docker socket. oCIS is a file. For anyone who has spent an evening on PHP memory limits, this lands.

Resource usage. On a small machine with a few users, oCIS idles in a couple of hundred megabytes and doesn’t sit there burning CPU on cron. The PHP-plus-database stack it replaced wants a gigabyte before it’s done anything interesting. If you’re counting watts — and I’ve made the case that you should be counting them — the difference is real, if modest at homelab scale.

No oc_filecache. The class of failure where the database and the disk disagree about what files exist simply stops existing. That was a large fraction of ownCloud’s historical support pain and the rewrite took it out at the root. This is what a rewrite is supposed to look like: an entire category of bug becomes unrepresentable.

Honest concurrency. Go’s runtime does what PHP-FPM’s worker pool always pretended to. Sync clients hammering the server with hundreds of parallel PROPFINDs is a normal Tuesday for oCIS.

Here’s a Compose arrangement close to what I ran, sitting behind an existing proxy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

services:
  ocis:
    image: owncloud/ocis:latest
    container_name: ocis
    restart: unless-stopped
    entrypoint: ["/bin/sh", "-c", "ocis init || true; ocis server"]
    environment:
      OCIS_URL: https://cloud.example.com
      PROXY_TLS: "false"                 # terminate TLS at the proxy
      OCIS_LOG_LEVEL: info
      OCIS_INSECURE: "false"
      PROXY_ENABLE_BASIC_AUTH: "false"
      IDM_CREATE_DEMO_USERS: "false"
    volumes:
      - ./ocis-config:/etc/ocis
      - ./ocis-data:/var/lib/ocis
    ports:
      - "127.0.0.1:9200:9200"

Point Caddy at 127.0.0.1:9200 and you’re done. PROXY_TLS: "false" is the flag everyone misses on the first attempt, and its absence produces a TLS handshake error that reads like a certificate problem.

What the rewrite cost

The app ecosystem is gone, and it isn’t coming back. This is the whole ballgame. Nextcloud has an app store with hundreds of things in it — calendar, contacts, notes, Deck, forms, a mail client, Talk. Some are excellent, most are mediocre, and the mediocre ones are still there when you need one. oCIS has a small set of extensions and no comparable ecosystem, because the PHP app API it would need was the thing they threw away. A decade of third-party work stayed on the old platform.

So oCIS is a file-sync server. It’s a good one. If your definition of “own your cloud” includes calendars and contacts, oCIS is one component of an answer and you’re assembling the rest yourself — a real cost when you’re planning a de-Googling migration and counting how many services you’re now on the hook for.

Extended attributes are load-bearing. The default storage driver stores metadata in xattrs. Put your data directory on a filesystem or mount that handles xattrs poorly — NFS is the classic offender, and some overlay and network mounts are worse — and you get corruption that looks like ghosts. Files vanish from the web UI while sitting plainly on disk. There has been work on a POSIX-friendly driver with a more legible on-disk layout precisely because this bit people, and the lesson is worth internalising even if you never touch oCIS: an architecture that eliminates the database has to put the metadata somewhere, and wherever it goes inherits the requirements.

The on-disk layout is opaque. Point a file manager at oCIS’s data directory and you’ll find a hashed node tree, not your documents. Classic ownCloud kept the files in a shape you could recognise, and the folk recovery plan — “worst case, I copy the folders off with rsync” — worked. It stops working here. Your recovery plan becomes the backup, entirely, which is the correct plan anyway and now the only one.

Five years of features you already had. External storage connectors, granular sharing behaviour, file-drop nuances, trash semantics, activity feeds — the long tail took years to reappear, and some of it never arrived. This is exactly Spolsky’s argument in its natural habitat. All those fiddly conditionals in the old code were bug fixes for real situations, and rewriting means rediscovering each one by hand.

The migration nobody enjoyed

Spare a thought for the people who ran ownCloud 10 in production and were told the future was a program that shared none of its data structures.

There is no in-place upgrade. There cannot be — the database that held all your metadata is the thing being deleted, and the on-disk layout is unrecognisable to the new code. The official path is a migration tool that reads the old installation and writes a new oCIS instance beside it, which means you need both running, enough disk for two copies of everything, and a maintenance window measured in “how big is your data” rather than minutes.

The parts that survive cleanly are the files themselves and the user accounts. The parts that need attention are shares — the classic share table maps onto Spaces awkwardly, because a shared folder in ownCloud 10 and a Space in oCIS are different objects with different membership semantics. Public links carry tokens that people have in emails and bookmarks, and those tokens do not follow. Anyone who published a link to a colleague in 2021 gets to explain why it stopped working.

My advice to anyone facing this, having watched two organisations do it: run the migration on a copy first, list every public link you have before you start, and decide in advance whether you’re migrating shares or declaring share bankruptcy and asking people to re-share. The second option is faster and more honest than it sounds. The same logic applies at homelab scale — the value is in the bytes, and everything else is worth rebuilding by hand if rebuilding is cheaper than translating.

The fork question

Here’s where it gets properly interesting. In late 2023 ownCloud GmbH was acquired by Kiteworks, an American enterprise-compliance vendor. Reasonable people can hold opinions about what that means for a European open-source project whose main pitch to European institutions was digital sovereignty.

In 2025, a fork appeared — OpenCloud, built on the oCIS codebase, driven by German infrastructure companies with long open-source histories and staffed in part by people who’d worked on the original. The pitch was continuity of the technology under governance that couldn’t be sold again.

I’m not going to tell you which one to run, partly because the situation was still settling as I write this and partly because forks are decided by momentum rather than merit. The observation worth taking away is structural: a from-scratch rewrite is the moment a project is most vulnerable to a governance shock. The old codebase is deprecated and its community has dispersed. The new one has no ecosystem lock-in yet, because there’s no ecosystem. Nobody’s third-party app breaks if the whole thing forks, because there are no third-party apps. The rewrite that freed ownCloud from its technical debt also freed everyone else from any reason to stay.

Troubleshooting

TLS handshake errors from the proxy. You forgot PROXY_TLS: "false". oCIS terminates TLS itself by default and will happily present its own certificate to a proxy that wanted plain HTTP.

ocis init refuses to run. It won’t overwrite an existing config. Deliberate, and correct:

1
2
3

docker exec ocis ls -la /etc/ocis/
# ocis.yaml already there? then init has run; go find your admin password
docker exec ocis ocis idm resetpassword -u admin

Files show on disk but not in the web UI. Check xattr support on the underlying filesystem before you check anything else:

1
2
3

touch /var/lib/ocis/testfile
setfattr -n user.test -v hello /var/lib/ocis/testfile
getfattr -d /var/lib/ocis/testfile

An error from setfattr, or getfattr returning nothing, means your storage cannot host oCIS data. Move it to real local storage. No amount of restarting fixes this.

Search returns nothing for files you can see. The indexer is a separate service and it can fall behind or die quietly while the rest of the process carries on:

1

docker logs ocis 2>&1 | grep -i search | tail -n 30

OIDC login loops back to the login page. The issuer URL in oCIS’s config and the one your identity provider advertises must match character for character, including the trailing slash. This burns an hour of everyone’s life exactly once.

Sync client authenticates then does nothing. Old clients speak the classic ownCloud auth flow; oCIS wants OIDC. Update the client, and mind that the desktop client and the server versions are released on their own schedules.

The verdict

oCIS is worth running if you want a fast, lean, S3-capable file-sync server for a handful of people or an institution, you’re content for it to do files and only files, and you’re going to store the data on a proper local filesystem with a backup you’ve actually tested. On those terms it’s better engineered than what it replaced, and the single binary is a real pleasure.

It’s the wrong choice if “own your cloud” means calendars, contacts, notes and an app store — that’s Nextcloud, warts and all — or if your recovery plan involves reading your own files off the disk with a file manager, or if you want the ecosystem stability that comes with a project nobody has just acquired.

As for the rewrite question: ownCloud proved a rewrite can succeed technically and still cost you the thing you had. The oc_filecache bugs are gone forever, the deployment story is a joy, and Nextcloud — the fork that stayed on the old PHP and kept patching it — remains the default answer when someone asks what to self-host for files. Both of those statements are true at once, and holding them together is the most useful thing you can take from five years of this experiment. Spolsky was right about the strategy and wrong about the code. The new code really is better. It just turns out the code was never the moat.