ElastOS is a local-first runtime for Apps and services. Runtime checks the authority of each caller before allowing an effect. People sign in to Home with passkeys.
For release history, see elastos/CHANGELOG.md. GitHub issues own current acceptance and verification. A source checkout and a published installation have separate artifact identities and verification records.
First-party apps run as web projections in the browser's opaque sandboxed frames. Runtime checks each app's signed launch token and actor before it performs an effect. Home can currently obtain every app's capability, so a compromised Home can reach those apps' authority. The target limits Home to delegation and gives each app a separate, revocable capability. The WASM Component authoring path runs in Wasmtime with memory and fuel limits and Runtime Bus hostcalls.
Providers run as native operating-system processes with the Runtime user's rights. Only the model provider is partly confined. The trusted shell helper also runs as a native host process. The web Terminal is disabled by default; host developer mode and closed guest registration are required to enable it. An enabled Terminal runs commands with the host user's rights.
The seed operator can read hosted data, wallet keys and recovery material. Passkeys control sign-in; stored data and keys remain accessible to the Runtime account and root while Home is locked. Protection against hosted operators and root, and against other software or OS users while a self-hosted Home is locked, is the target of hosted protection and locked Home protection. An unlocked self-hosted Home trusts its owner and their host software. Recovery from a stolen device or profile key requires a new identity.
The isolation plan records the remaining gates. Source checks describe this source tree. Accepted installed proof binds the exact Runtime, components and app assets to the journeys tested on that device.
The public installer looks up signed releases for Linux x86_64/aarch64 and macOS Apple silicon. Intel Mac and other OS families fail closed.
The maintainer release DID is
did:key:z6MkgwHd2BCWe1jHMXPiR6H1q1RFPcv1YzhMbK5G1kBarbfe. Compare the
installer's Maintainer DID: line with this complete DID. Stop if they differ.
The maintainer changed the release signing key because the previous key was stored on the public server.
curl -fsSL https://elastos.elacitylabs.com/install.sh | bashFor an existing Home, re-trust the maintainer once by running the same installer over the old installation:
curl -fsSL https://elastos.elacitylabs.com/install.sh | bashThe installer trusts the new DID, installs the release and keeps your existing identity, accounts and user files. Homes that already trust this DID can use normal updates. See release signer recovery.
The installer installs Runtime, sets up the Home profile, and opens Home. Its
release acceptance evidence lives in GitHub issues. Keep the terminal open while you use Home. Add $HOME/.local/bin to PATH when you
later run elastos from a new shell. You do not need a separate elastos serve
process for this path. Home is the user-facing front door to the managed
Runtime.
Only one live host may own an ElastOS data home at a time. Stop Home before using the separate operator runtime in the same home. See Installing ElastOS for updates, trust verification, and operator setup. See the Mac staging runbook for source-home staging and Browser VM work.
The workspace requires Rust 1.91 or newer.
cargo install just
just build
just testA source build does not create a complete install. Use Getting
started for trusted-source setup, running a source
build, and capsule development. Run just verify before handing off a change.
Runtime is the trusted core. Home and shells show state and collect intent. The target limits their authority to Runtime-approved delegation. Executable capsules request effects through typed Runtime resources. Components use ElastOS Bus. Web projections use narrow, capsule-scoped Runtime adapters. Both enter Runtime's authority and routing boundary. Runtime handles core operations directly and selects a provider for provider-backed effects. Carrier is the endpoint-authenticated off-box transport for routes that leave the node, not the capsule API.
Self-contained host commands and explicit operator commands use their
documented paths inside the elastos binary. They are outside the capsule
effect path. The architecture defines the trust
topology. The command matrix defines command
ownership.
ElastOS keeps three concepts separate:
- objects are a person's documents, media, identities, sites, and other things
- Digital Capsules are complete, portable signed packages
- spaces are the rooted namespaces where objects and services resolve
Public product surfaces use "Apps." Runtime and developer documents use
"capsules." Directories under capsules/ and templates/ are source packages.
They become Digital Capsules only when completely packaged and signed. Runtime
admission is a separate, node-local verification decision. See the
principles and
architecture for the full model.
Use GitHub issues for current behavior, known gaps and proof. Install and update #89 owns installed release acceptance. A source checkout and a published install have separate artifact identities; source checks alone do not prove installed product or Browser support.
ROADMAP.md links planned work; elastos/CHANGELOG.md records release history.
For command ownership across Home and operator lanes, see the command matrix.
elastos-runtime/
├── elastos/ # Rust runtime workspace
├── capsules/ # First-party capsule source packages and projections
├── docs/ # Guides, contracts, architecture, and runbooks
└── scripts/ # Build, verification, release, and operator tools
- Getting started: install, build, and create a capsule
- Documentation map: complete guide and contract index
- Isolation plan: current boundaries and acceptance gates
- Principles: decision constraints
- Architecture: trust and responsibility boundaries
- Capsule authoring: supported Component and web-projection paths