Latent Service Fabric (LSF) runs stateless service capsules on a standalone Linux node. A capsule is a WebAssembly component with typed interfaces and declared capabilities. Deploying another service adds code and bounded metadata; it does not create an idle service process, thread, socket, guest heap or connection pool.
An incoming request creates an activation in a fixed pool of execution cells. Each activation gets fresh guest state. The node reclaims its resources when the request finishes, fails, times out or is cancelled.
Start with application development. Install the packaged tools, create a greeting in Rust, C, TypeScript, Go, Java or C#, and run it on a local development node. The controller creates the private credentials and manages build, test, edit/watch, restart and cleanup. Your application stays outside the LSF checkout; you do not build LSF itself.
Use Windows x86-64 with WSL2 or supported Linux x86-64. An explicit SSH backend and optional development container use the same workflow. Native Windows can also run the supported portable tests on already compiled capsules.
For a persistent Linux server, follow native installation. Run a node from source remains available for contributors and readers who want to inspect the lower-level steps.
LSF is experimental. The 0.1.0-alpha.5 distribution separates the native
server runtime from the controlled development toolkit. Use the matching
installation and support instructions; an alpha release
does not certify hostile multitenancy or production performance. The historical
0.1.0-alpha.3 release is source-only.
The documentation website provides Start, Learn, How-to, Reference, Understand and Contribute sections. Choose the development documentation for this branch; published versioned guides describe their own release and may differ from the current source.
| Goal | Current support | Start here |
|---|---|---|
| Run a stateless service | Typed Component Model contracts, bounded execution and fresh state per activation | Create a capsule |
| Call a service from an application | Native Rust, C, TypeScript, Go, Java and C# clients using the shared local RPC profile | Client guide |
| Use host capabilities | Policy-controlled providers with shared pools and activation-owned resources | Use capabilities |
| Serve a website | Angular/PrimeNG and Docusaurus build recipes, signed static packages, recoverable GET/HEAD cutover and optional edge gzip | Deliver a website |
| Combine a website and an API | Static publications and a restricted TypeScript HTTP service under one origin | Static site and API |
| Operate a container node | Non-root Linux profile, private CI and probes, TLS edge, consistent backup and exclusive ownership handover | Container guide |
| Render an Angular application | A supported, bounded server-rendering profile with browser assets | Angular walkthrough |
| Deliver and recover changes | Signed packages, OCI transfer, admission, managed deployment, staged rollout, canary observation and rollback | Delivery guide |
External client support and capsule authoring are separate: all six client languages can call LSF, and each has a dedicated guest authoring path with documented supported profiles and limitations. The guest SDK guide describes the available build paths without implying that every external client is also a guest SDK.
SDK packages and developer bundles in this release use 0.1.0-alpha.5.
C and Go source SDKs follow the repository release tag; they do not have a
separate package version. Keep the toolkit and its authenticated selection
together when upgrading, using a fresh input directory as described in setup.
Standalone node configuration exposes outbound HTTP, local blobs, activation clocks and OS-backed randomness through explicit provider installations. Other maintained provider integrations use trusted Rust embedding; consult the provider reference before choosing a setup. Durable application state, transactional effects and clustering remain planned work. Management RPCs are local; application HTTP ingress has its own listener and security configuration.
resident state = fixed node runtime + bounded catalog metadata + active activations + bounded shared caches
The number of node processes, threads, sockets and execution cells must not grow with the number of deployed services. Runtime limits bound queues, budgets, provider resources and retained results. Cleanup uncertainty keeps a cell quarantined and accounted for instead of making it available for reuse.
A signature, a package checksum and an invocation ID have different purposes. Package verification establishes provenance; current policy and admission decide whether execution is allowed. Capabilities require explicit grants. The current in-process runtime is not a separate-process security boundary against an engine compromise. Read architecture, execution security profiles and security reporting for the supported boundary.
| Path | Contents |
|---|---|
apps/ |
latentd standalone node, latent operator CLI and the clustered control-plane placeholder |
crates/ |
Runtime, storage, policy, provider and management implementations |
wit/ |
Typed capsule interfaces and platform capability contracts |
api/proto/ |
Invocation, node and management RPC definitions |
schemas/ |
Declarative resource JSON Schemas |
sdk/ |
External clients, common profile and guest bindings |
examples/ |
Capsule, application, contract and deployment examples |
docs/ |
Guides, references, architecture and engineering records |
adr/, rfcs/, research/ |
Accepted decisions, future proposals and experimental work |
tests/, benchmarks/ |
Test specifications and retained measurements; executable tests also live with their implementations |
tools/, website/ |
Build and validation tools and the documentation site |
WIT defines guest interfaces, Protobuf defines RPCs, and JSON Schema defines declarative documents. SDKs and generated bindings consume those authorities; they do not define independent wire contracts.
Start with CONTRIBUTING.md for the change workflow and toolchain setup for exact supported versions. After installing those prerequisites, the normal Linux validation entry point is:
python3.13 -m venv .venv
. .venv/bin/activate
python -m pip install --requirement tools/requirements.lock
make validateFor a focused change, use the local test runner to select the relevant registered suite. CI uses reviewed change profiles; generated files stay in build output directories. Expensive scale probes and resource campaigns require explicit selection. VALIDATION.md explains coverage and limits.
Engineering records retain past gate decisions and measured comparisons with their original source and environment. They are evidence for those runs, not current installation instructions or a claim of production cluster capacity.
Apache License 2.0. See LICENSE.