OpenCloud: file sync and sharing, built in Go without a database

Simple and sovereign, as a product thesis

OpenCloud presents itself as the open source platform for file management, sharing and collaboration, with the tagline simple and sovereign, a word choice aimed squarely at the European market's data-sovereignty concerns. The company behind it, OpenCloud GmbH, publishes the server under Apache 2.0, and the general documentation and installation guidance live in the project's GitHub organization and website rather than inside this repository, which is deliberately scoped as the server backend, the golang codebase for the backend services. Activity is immediate, the repository was pushed today, and the version line is fresh, v7.5.0 in August 2026 followed by v8.0.0 and v8.0.1 in mid-September, with a backport configuration in the tree suggesting the same dual-line maintenance discipline seen in serious infrastructure projects.

No database, the filesystem is the storage

The most striking sentence in the technology notes is plain, the OpenCloud backend does not use a database, it stores all data in the filesystem, with the root directory defaulting to $HOME/.opencloud. For operators this is a consequential simplification, backup becomes filesystem snapshotting, inspection becomes ordinary file tools, and there is no database engine to tune, replicate or recover. For architects it is a statement of confidence that a POSIX filesystem plus the service layer is sufficient coordination substrate for a file platform, which is a defensible position precisely because the product's own subject is files. Every design choice has a cost, and the trade here is that scaling characteristics depend on the filesystem and the service orchestration rather than on a database's maturity, a trade teams should evaluate against their own storage infrastructure.

OpenID Connect, with two identity paths

Authentication is exclusively OpenID Connect, with two documented paths, an external identity provider such as Keycloak, or the embedded LibreGraph Connect identity provider that ships inside the product. The embedded option matters for adoption, a small organization can run OpenCloud without standing up a separate IdP first, while the external path serves enterprises whose identity infrastructure already exists, and the Go dependencies show both taken seriously, a Keycloak client library alongside the core OIDC handling. Identity is also where the ecosystem lineage is visible, LibreGraph being the open standards work growing beside the CS3 APIs from cs3org that appear in the dependency list, the interoperability track of the ownCloud ecosystem that this platform builds upon.

Forty services behind one gateway

The Makefile enumerates the module list, and it reads like the anatomy of a file platform, a gateway fronting everything, four storage services split by concern into users, shares, public links and system, webdav and webfinger for protocol compatibility, sharing, collaboration and invitations for the human layer, users, groups and idm for identity, graph for the modern API surface, and ocm and ocs for federated and legacy interoperability. Around them sit the platform services, thumbnails, search, antivirus, postprocessing, policies, notifications, activity and user logs, event history and server-sent events, an app provider and registry, and five separate authentication services distinguishing app, basic, bearer, machine and service credentials. The dependency list confirms the machinery, go-micro for the service framework with gRPC, NATS for messaging, bleve for search indexing, libvips for image processing, ClamAV bindings for antivirus and Tika for text extraction.

Two commands from source to running server

The build path is documented in three steps. Generate the assets needed by the web UI and the builtin identity provider with make generate, compile the binary with make -C opencloud build producing opencloud/bin/opencloud, and start a local test instance with a two-part command:

opencloud/bin/opencloud init && opencloud/bin/opencloud server

The init half creates the server configuration, by default under $HOME/.opencloud, and the server half starts it, so a developer moves from clean checkout to running platform without composing files by hand. The development documentation at docs.opencloud.eu carries the remaining setup and installation options, including the deployment configurations kept in the repository's deployments directory, and the Dockerfile offers a source-build path for machines without the toolchains, built in three stages from Node asset generation through the Go compile to an Alpine runtime carrying vips and certificates.

Woodpecker CI, transifex and PHP remnants

The engineering infrastructure mixes the modern with the inherited. Continuous integration runs on Woodpecker with a starlark-generated pipeline configuration, code quality through Codacy, Go tooling through golangci-lint and mise for version pinning, and agent configuration directories for the usual assistants. Localization is systematic, a transifex-managed set of modules covering activitylog, graph, notifications, userlog and settings, and the documentation is multilingual. The inherited layer peeks through in composer.json, phpcs.xml and a vendor-bin directory running PHP code style tools, fingerprints of a codebase history that included PHP, kept tidy rather than excised, the pragmatic choice for a project whose priority is the shipping platform.

Positioned against the incumbents

The file sync and share field has two long-standing open source incumbents in ownCloud and Nextcloud, and OpenCloud's differentiation is architectural rather than philosophical, a Go microservice backend, filesystem-native storage with no database, and OIDC-native identity, against the PHP lineage of the incumbents. The tagline's sovereignty framing targets organizations that must reason about where their software and their data legally reside, and the GmbH structure provides a vendor to hold accountable. Community channels run through Matrix rather than the forums of the older projects, contributions of documentation and code review are explicitly solicited alongside patches, and security issues route to a dedicated address, [email protected]. For teams choosing today, the honest summary is that this is the newest serious entrant in an old category, betting that a clean Go foundation outlives the incumbents' installed bases.

Editorial conclusion

Use OpenCloud when you want a self-hosted file sync and share platform with a sovereign, European provenance, a Go backend and filesystem-native storage that simplifies backup and inspection. Prefer Nextcloud if its PHP ecosystem and vast app catalog matter more to you than the architectural differences, since both solve the same problem. Verify first whether your identity infrastructure speaks OpenID Connect, since that is the only authentication path, confirm your deployment fits the filesystem-storage model, and consult the documentation at docs.opencloud.eu for Docker and production setups before the first rollout.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opencloud-eu/opencloud on GitHub
3. Project website
4. README
5. Releases