← All work

Distributed hosting · Developer tools · Open source

Evolve Hosting

Run a piece of the commons. Publish a signed browser application, host a verified copy, and support the people who keep it available. No central app server is required for the static release.

Evolve Hosting verifying a signed application and showing its release, mirrors and hosting commands
The workspace checks signatures and every asset hash locally. Uploaded bundles are never executed here.

Why I built it

Our browser projects can run with a small hosting footprint. Fairground already distributes public data through independently operated relays and offers direct optional support. Evolve Hosting applies that model to static applications: portable releases, replaceable mirrors and visible recipients, with a CLI anyone can run.

Try it

Open the release workspace → Verify the signed Commons Board example, inspect its files, download the bundle and public key, check mirrors, or import your own release without uploading it.

Try Commons Board → A small checklist runs entirely in your browser. Its data stays on each origin; moving between mirrors does not synchronize private browser storage.

Publish, verify and host

A publisher selects an explicit list of public assets. The CLI signs a manifest with Ed25519 and records each file’s size and SHA-256. An operator supplies a separately trusted public key, verifies every file, then serves the release locally or exports a complete directory for a static host.

Activation preserves the previous release for rollback. A pinned project identity, trust-key fingerprint and increasing sequence reject unexpected signers and replayed updates. A corrupt import cannot replace the active app. The default Node server binds to loopback; public operators configure their own HTTPS and resource limits.

Recovery we measured

The recorded drill starts two separate Node CLI processes with separate mirror stores. They serve identical application responses. A corrupted update is rejected, the prior release stays active, and the second mirror remains usable after the first process stops.

This is a local process drill, with actual timings and an explicit scope. The two public examples use EvolveTech’s existing Netlify and Bunny providers under the same operator. Independent community participation is open; no participating community operators or worldwide availability guarantee is claimed.

Near-zero required publisher cost

The goal is to make small static applications practical on existing machines, donated capacity and free-tier hosting within provider limits. Operators still supply storage, bandwidth, electricity and maintenance. Domains, optional providers and network fees remain real costs.

This release provisions no paid cloud resources. It reuses our existing website infrastructure; no monthly billing total or zero-cost-at-scale claim is made. The operations and cost record separates publisher costs, contributed capacity and optional donations.

Wallet setup

Follow the wallet setup walkthrough → Save or restore the account, find its receiving address, transfer ALGO while Meld checkout is unavailable, and check when the wallet can receive USDC. Project operators can also check the shared donation fund’s readiness. Credentials stay private.

Support through Fairground

The app reuses Fairground’s pinned Algorand payment code. Donors choose recipients and amounts, check readiness, and explicitly open their own external wallet. Payments go directly to recipients in native USDC, with no pooled funds or wallet keys held by the hosting app.

Receipt checks match the network, asset, recipient, exact amount, unique note and confirmation time. Browser tests cover separate development and hosting payments using fixtures; no real transfer is sent. The example has one development recipient and no community hosting recipients. The development fund still needs USDC opt-in; the UI checks readiness before preparing links.

Trust and limits

A key supplied by an untrusted mirror is not an independent trust root. Browser checks cannot authenticate their own initial page; use a trusted bootstrap or the local CLI. Mirror health checks compare reported metadata, not every remote response. See the security model and test evidence.

Private APIs and databases need their own operators and recovery plans. This release does not implement relay discovery, peer file transfer, automatic updates, offline service workers, card checkout or automatic hosting rewards. A failed initial domain needs a known alternate URL, a local copy or working DNS recovery.

Status
Early release; two provider copies and a recorded local recovery drill
License
Apache 2.0
Built with
Node.js, JavaScript, Ed25519, SHA-256, static HTTP mirrors, Fairground payment rail