Ourcld

Early · in development · open source

Hosting you own, down to the name.

Ourcld is an open-source distributed hosting platform built for privacy, security, and decentralization. Your names are user-controlled, your releases are content-addressed, and your mutable data is encrypted before it leaves the client and spread across independent hosts.

Read the architecture Follow on Git
  • ArNS names, user-owned
  • Filecoin Pin by default
  • Arweave "forever" option
  • Sia encrypted buckets
# planned CLI flow (v1 is in development)
$ ourcld deploy
  build      static site
  upload     tree → Plane A
  root       bafy…  (content-addressed)
  pin        Filecoin Pin (renewable)
  name       staging_myapp → root  atomic
$ ourcld env promote
  name       @myapp → root          atomic
  serve      https://myapp.…       TLS
Illustrative only: the deploy → pointer flow from the v1 architecture. Commands and output are not final.

What Ourcld does

Built on protocols, not promises

Hosting is not the same thing as storage. Ourcld keeps bytes, names, and runtimes as separate layers, so each one can be decentralized on its own terms.

You own your names

Names are decentralized and user-controlled from day one. v1 uses ArNS, with undernames for staging; ENS and DNSLink adapters come later. Ourcld deploys and serves your name, but it is not the registrar of record.

Content-addressed releases

Every deploy is an immutable, content-addressed build with a manifest, so deploys are atomic and a rollback just points the name at a prior root. Releases use a renewable Filecoin Pin by default. You can add an optional permanent "forever" archive on Arweave through Turbo.

Encrypted mutable storage

Mutable buckets live on Sia. Data is encrypted on the client and erasure-coded across independent hosts, and no single storage company sits in the data path. The indexer that coordinates metadata can be self-run.

S3-compatible, tested with Forgejo

The Sia leg speaks S3 through the Sia Foundation's s3d. We tested it with Forgejo on Sia's Zen testnet, covering LFS (including a 150 MiB multipart upload), attachments, avatars, restarts, and deletes. It passed 19 of 20 tests. The one gap: with direct serving enabled, attachment downloads lose their filename.

Proofs, not a pin daemon

Persistence is proven, not assumed. A proof and renewal watcher checks storage health and raises an alert when data is under-replicated, and the aim is to show replication health rather than just "uploaded."

Open source control plane

The API, CLI, and gateway are open source, and storage providers plug in as adapters. The goal is that a backend can be swapped without changing the CLI contract.

Architecture

Three planes, cleanly separated

A content address is not a user-facing name. Ourcld keeps CIDs and blob IDs under the hood and puts a human name on the outside. That split creates three planes.

C Compute (thin)
Static sites first. Later, one container service per project, which pulls release artifacts from Plane A.
B Naming & routing the core
Names, TLS, gateways, staging and prod pointers, and deploys. This plane is the actual "hosting."
A Storage & blobs
Immutable releases (Filecoin Pin, optional Arweave forever) plus mutable, encrypted buckets (Sia).
Ourcld three-plane architecture Three stacked layers. Plane C, compute, is on top and pulls artifacts from below. Plane B, naming and routing, is in the middle, is highlighted as the core, and resolves a name to a content root. Plane A, storage and blobs, is at the bottom and contains Filecoin Pin, the Arweave forever option, and Sia encrypted buckets. PLANE C Compute (thin) static sites first · containers later pulls artifacts PLANE B · CORE Naming & routing ArNS names · TLS · gateway · cache · pointers name → content root PLANE A Storage & blobs Filecoin Pin Arweave forever Sia (encrypted)
The gateway in Plane B resolves a name to a content root in Plane A. Compute in Plane C stays optional and thin in v1.

How it works

From deploy to a live name in four steps

  1. Deploy

    Run the CLI or a CI action. It builds your static site and uploads the file tree to Plane A.

  2. Content-addressed storage

    The build gets a root CID and a manifest. It is pinned with Filecoin Pin by default, and you can archive it forever on Arweave.

  3. Name resolves

    Your name pointer, prod or a staging undername, moves atomically to the new root. You can roll back by pointing it at the previous root.

  4. Gateway serves

    The gateway terminates TLS, resolves the name, then fetches, caches, and serves the content. It fails over across multiple origins.

Behind the scenes, a persistence job verifies proofs and renewals and alerts if content is under-replicated.

Why decentralized

Fewer single points of failure, and of control

Traditional hosting usually ties your name, your bytes, and your uptime to one provider. Ourcld pulls those apart.

Single-provider hosting compared with the Ourcld approach
Concern Single-provider hosting Ourcld
Who controls the name Often tied to the host's account and platform You do. It's a user-controlled ArNS name, and Ourcld is not the registrar
Where the bytes live One company's infrastructure Independent providers on Filecoin, Arweave, and Sia
How persistence is known Trust the provider's word Storage proofs and renewals, with health monitoring
Integrity of a release Files can change in place Content-addressed: the address is derived from the bytes
Private object data Readable by the storage provider Encrypted before upload and erasure-coded across hosts (see the v1 trust note)
Leaving Migrate everything, then re-point the name Backends are pluggable adapters, and your name comes with you

First user

Built alongside MeritForge

Ourcld's first user is MeritForge, an open-source Git SaaS that pays its contributors. MeritForge runs on Forgejo. Its object storage (Git LFS, attachments, and avatars) targets Ourcld's Sia-backed, S3-compatible buckets. Bucket prefixes stay the same when it moves off an interim store.

This is an early, in-development deployment, not a production case study.

  • Forgejo 11 using S3 storage on s3d, backed by Sia's Zen testnet
  • Git LFS, including a 150 MiB multipart upload with verified checksums
  • Issue attachments, user avatars, and repo avatars
  • Persistence after a restart, with reads served from Sia hosts
  • Repo deletion cleans up its stored objects
  • Known gap: with SERVE_DIRECT enabled, attachment downloads lose their filename

Honest trust note

What you trust us with in v1

  • In v1, the gateway holds the project's storage key. Data on Sia is encrypted, but the Ourcld gateway acts as the trusted decryptor for a project. That means the operator could technically read that project's mutable objects. It is the same class of trust as "we host your MinIO."
  • You also trust Ourcld for TLS, billing, and gateway correctness in v1. You don't need to trust any single storage provider for durability.
  • Public means public. Published sites are public by design, and anything archived "forever" on Arweave is permanent and public. Never send private data there.
  • Roadmap: per-tenant keys, then customer-held keys, and later user-run gateways to reduce trust in the Ourcld edge.

Roadmap

Where this is going

Phases, not promises. There are no dates yet.

  1. v1In development

    Storage + naming

    Planes A and B: static hosting with projects and prod/staging environments, ArNS naming, Filecoin Pin with the forever option, Sia buckets, a gateway with cache and failover, and proof watching.

  2. v1.1Planned

    Thin compute

    Plane C: attach one container service per project through a first compute adapter (Akash-first).

  3. v1.2Planned

    Payment abstraction

    Pay in one place while Ourcld settles storage providers in whatever they need.

  4. v2Planned

    Less trust in us

    User-run gateways and federated naming, plus the move to per-tenant and customer-held keys.

  5. LaterPlanned

    More name systems

    ENS and DNSLink adapters alongside ArNS.

Follow along while it's being built

Ourcld is early and developed in the open. Read the design, watch the repository, and help shape it.

Read the architecture Follow on Git