Skip to content

Alternatives to this platform

Products and approaches that can replace all or part of ECMWF Sites: what each one is, what it is not, its strengths, and where it stops.

Purpose and scope

This page gives context. It is the only page in this section that does not describe implemented behaviour of this repository, so it has no behaviour requirements table. Statements about external products were checked against the products' own documentation in November 2026. The sources are listed in References. Product capabilities change. Check the source again before you base a decision on one statement here.

What this platform provides

The comparison uses this baseline. ECMWF Sites gives each tenant Site:

Capability On this platform
Self-hosting Runs on your own Kubernetes clusters. The platform code is Apache-2.0
Tenant isolation One pod, one persistent volume claim (PVC), and one proxy per Site
Identity OpenID Connect (OIDC) login for browsers. API tokens, session tokens, signed URLs, and shared links with expiry and path scope for machines and anonymous users
Content operations HTTP upload, download, and list API (v1 and v2, resumable uploads), WebDAV, and an S3-compatible endpoint over the same files
Applications Static content by default. Optional custom container applications per Site, behind the same proxy and authentication
Lifecycle Storage quota per Site, retention dates with archive and delete jobs, backups, and usage notifications
Administration The Hub web UI and REST API for Site management, branding, and platform configuration

No single external product provides all seven rows. The sections below group the closest candidates by the part of the platform they could replace.

Alternatives to the platform layer

These tools could replace the way this platform is built: the Site Custom Resource Definition (CRD), the operator, and the exporter. None of them replaces what the platform does.

kro (Kube Resource Orchestrator)

  • What it is: A Kubernetes controller from the Kubernetes Special Interest Group (SIG) Cloud Provider (kubernetes-sigs/kro, backed by Amazon Web Services (AWS), Google, and Azure). You write a ResourceGraphDefinition: a schema for a new API, plus templates for the Kubernetes resources each instance produces, wired together with CEL (Common Expression Language) expressions. kro generates the CRD and a dedicated controller at runtime, infers the dependency order, and reconciles instances. AWS offers kro as a managed Amazon Elastic Kubernetes Service (EKS) capability. The ResourceGraphDefinition API is stable; the newer Graph API is alpha.
  • What it is not: A hosting product. It has no user interface, no authentication, no file API, no tokens, no quotas, and no lifecycle jobs. It builds APIs for other people to fill with resources.
  • Strengths: Removes most of the glue code of a hand-written operator. CEL is type-checked at apply time, always terminates, and has no side effects, so a definition is auditable. It composes any native resource or CRD.
  • Where it stops against this platform: CEL cannot render the per-Site OpenResty configuration set, hash identities, or run the export logic; that stays in code or scripts outside kro. A "Site" definition built with kro would produce the pod, PVC, Service, and Ingress skeletons only. You would still build the proxy rules, the token model, the Site API, the Hub, the quota, retention, and backup jobs, and the UI: the whole product.

Crossplane

  • What it is: A Cloud Native Computing Foundation (CNCF) graduated project (October 2025) and a framework for building control planes without writing controllers. A CompositeResourceDefinition (XRD) defines a new API; a Composition maps each instance to a pipeline of functions that produce managed resources. Providers exist for the major clouds, Kubernetes, Helm, and Software as a Service (SaaS) APIs. Crossplane v2 compositions can include any Kubernetes resource.
  • What it is not: A web hosting or file sharing product. Like kro, it is the composition engine, not the service being composed.
  • Strengths: More mature and more extensible than kro: function pipelines in several languages, a large provider ecosystem, continuous drift correction, and Kubernetes role-based access control (RBAC) over the platform API itself.
  • Where it stops against this platform: The same boundary as kro, plus an operational one. Everything tenant-facing still needs an implementation: authentication chains, tokens, the file API, the rendered proxy configuration, and the Hub. Crossplane also replaces the API group and controller layer that the Sites operator and chart already provide, so it adds a second framework without removing a single product component.

Plain Helm chart plus a custom operator

  • What it is: The approach this repository takes: a CRD, a controller for the lifecycle, an exporter that renders every per-Site object, and a chart for the platform layer.
  • What it is not: A shortcut. It is the most code of the three options in this section.
  • Strengths: Full control of behaviour, schema, and validation. No dependency on the expression limits of a composition framework. The rendering logic is plain Python and testable.
  • Where it stops: You own the controller, the API compatibility, and the upgrades. This is the deliberate cost the rest of these documents describes.

Self-hosted sharing and storage products

These products replace the content operations rows of the baseline: files, sharing, and some of the governance. They do not replace per tenant websites or applications.

Nextcloud

  • What it is: The largest self-hosted sync-and-share suite (PHP, GNU Affero General Public License (AGPL)): files, versioning, links, calendars, contacts, Talk, Office, and about 500 apps. WebDAV is the native protocol. OIDC comes from the user_oidc app, quotas are per user or group, and a retention app applies rules to file versions. An admin web UI and a REST API cover ordinary operation.
  • What it is not: A site publishing platform. It serves its own PHP UI; it does not host arbitrary static sites, and it does not run per-user container applications. "External sites" apps only add links. It is also not built for hard multi-tenancy: one instance models one organisation, with folders and access control lists (ACLs) as the boundary, not a sandboxed space per tenant.
  • Strengths: Broadest feature set in this category. Large community and vendor support. Clients for desktop and mobile.
  • Where it stops against this platform: Tokens are user-scoped share links, not path-scoped, expiring API credentials with machine semantics. There is no per-tenant storage quota backed by a volume, no retention-to-archive workflow per tenant, and no S3 endpoint for tenant content. The release cadence (a new major about every four months, supported for one year) keeps upgrade work high.

Seafile

  • What it is: A self-hosted sync-and-share platform built on block-level libraries with content deduplication. Share links carry expiry and passwords. WebDAV, a REST API, and per-library permissions exist. It can use S3 for its backend storage.
  • What it is not: A website host, an application host, or a hard multi-tenant system. The paid Professional edition adds Security Assertion Markup Language (SAML) and some admin features.
  • Strengths: Efficient sync and versioning on large file trees. Lighter to operate than Nextcloud.
  • Where it stops against this platform: Same boundaries as Nextcloud for sites, applications, quotas at volume level, and an S3-compatible front end.

Pydio Cells

  • What it is: A Go rewrite of Pydio: a content collaboration platform with workspaces, fine-grained ACLs, share links, WebDAV, a REST API, and S3 backends. The community edition is AGPL, and the project is active (version 5 shipped in 2026). A commercial edition adds single sign-on (SSO) integrations and support.
  • What it is not: A site or application host. Workspaces isolate content within one instance; they do not sandbox per tenant processes.
  • Strengths: Single Go binary to start with. A clean permission model over multiple storage backends.
  • Where it stops against this platform: No per-tenant volume quota, no retention jobs, no S3 front end for tenant content, and no website publishing.

MinIO

  • What it is: A self-hosted S3-compatible object server (AGPL) with erasure coding, presigned URLs, bucket policies, lifecycle rules, and object locking.
  • What it is not: A website or file sharing portal. Buckets have only minimal static hosting hooks: no listing UI of substance, no expiring path-scoped tokens with the Site API semantics, and no browser login flow for content. Most of the administrative web console was removed from the open-source build in 2025; the current community UI is reduced.
  • Strengths: The most faithful S3 behaviour outside AWS. Simple scale-out. Lifecycle rules give object-level expiry.
  • Where it stops against this platform: No per-bucket hard storage quota, no WebDAV, no site lifecycle, and no tenant administration UI. MinIO is the closest match for the S3 row of the baseline alone.

Managed hosting services

These services replace the platform as a service. They are the usual choice when self-hosting is not a requirement.

GitLab Pages

  • What it is: Static site publishing built into GitLab: a CI job uploads an artifact directory, and the Pages daemon serves it per project. It comes with self-managed GitLab, so your own infrastructure hosts the sites.
  • What it is not: A file sharing or storage platform. Content arrives through Git or CI, never through a user-facing upload API. There is no WebDAV, no S3, and no per-site quota or retention.
  • Strengths: Zero extra components if you run GitLab. Optional access control ties a site to project membership, and an access token can authenticate API requests to a private site.
  • Where it stops against this platform: Sites are read-only artifacts, tokens are GitLab credentials rather than share credentials, and tenant size limits follow CI artifact rules.

GitHub Pages

  • What it is: Static hosting tied to repositories (github.com-managed).
  • What it is not: Available for self-hosting. Public by default on free plans; restricted visibility needs an Enterprise plan.
  • Strengths: No setup for repository content, with build integration.
  • Where it stops against this platform: No upload API for tenants, no share tokens, no WebDAV or S3, and size and bandwidth guidance limits.

Cloudflare Pages, R2, and Access

  • What it is: Managed static and JAMstack hosting (Pages), S3-like object storage with no egress fees (R2), and a Zero Trust login layer in front of hosts (Access).
  • What it is not: Self-hosted. The content and the access policy live with the provider.
  • Strengths: Global delivery, preview deploys, lifecycle and signed URLs on R2, and Workers for dynamic behaviour.
  • Where it stops against this platform: The governance rows of the baseline (per-tenant volume quota, retention jobs, platform branding, the Hub) are yours to rebuild across provider APIs, and data jurisdiction leaves the building.

Netlify and Vercel

  • What it is: Managed web-app hosting with deploy APIs, preview environments, functions, and paid access protection.
  • What it is not: Storage platforms or self-hosted software.
  • Strengths: The best build-and-preview workflow for application front ends.
  • Where it stops against this platform: File sharing semantics (tokens, WebDAV, S3) and tenant lifecycle governance are outside the product. Use them when the tenant content is a deployable web app, not data.

The minimal do-it-yourself option

Plain nginx with autoindex and auth_basic

  • What it is: The pattern this platform automates: virtual hosts, autoindex for the listing, auth_basic with .htpasswd files, and an alias or mount per tenant.
  • What it is not: A platform. Nothing manages the tenants.
  • Strengths: Almost no moving parts. Every operator already knows it. It is a fair baseline for what the per-Site proxy does.
  • Where it stops against this platform: Tokens with expiry and scope, quotas, retention, backups, OIDC, a self-service UI, an upload API, and the reconciliation between them all are the product. Sites grew from exactly this baseline; see site proxy design.

Capability summary

kro, Crossplane, and the operator approach do not appear in this table: they provide none of these capabilities by themselves. In the table, Yes means the capability is standard, Partial means an add-on, an edition boundary, or a material limit, and No means the product does not provide it. The profiles above carry the details.

Capability ECMWF Sites Nextcloud Seafile Pydio Cells MinIO GitLab Pages Cloudflare / Netlify / Vercel Plain nginx
Self-hosted Yes Yes Yes Yes Yes Yes No Yes
Per-tenant isolation of compute and storage Yes No No No Partial Partial Partial No
Browser login through OIDC Yes Partial Partial Partial Partial Partial Partial No
Scoped, expiring share tokens Yes Partial Partial Partial Partial No Partial No
HTTP upload API for tenant content Yes Yes Yes Yes Yes No Partial No
WebDAV Yes Yes Yes Yes No No No Yes
S3-compatible front end for tenant content Yes No No No Yes No Partial No
Static website per tenant Yes No No No Partial Yes Yes Yes
Custom application per tenant Yes No No No No No Partial No
Storage quota per tenant Yes Partial Partial Partial No No Partial No
Retention and archive workflow Yes Partial Partial Partial Partial No No No
Tenant administration UI and API Yes Yes Yes Yes Partial Partial Yes No

When to choose what

  • If you only distribute objects to machines, use S3 or MinIO. Its signed URLs cover most of the token row.
  • If people must collaborate on documents, use Nextcloud or a similar suite. Do not make it host websites.
  • If the content lives in repositories and is published as static sites, use GitLab Pages or GitHub Pages.
  • If the team has no operations capacity and data jurisdiction is not a constraint, use a managed host.
  • If you are building an internal platform on Kubernetes and your product is not file sharing, kro or Crossplane can remove operator boilerplate from your design.

This platform is the choice when all of these must hold at once: tenants publish websites and data, machines share content with scoped tokens and WebDAV or S3, the organisation keeps storage quotas, retention, and backups under governance, and everything runs on infrastructure the organisation controls. No product surveyed here combines those rows. That combination, per tenant, behind one OIDC login, is the reason ECMWF Sites exists.

References

Sources checked November 2026.