§24 Loams Functions: a CPU-Time Serverless Runtime

Status: Proposed · 2026-09-29; amended the same day by two owner decisions (D189: secrets through Dapr; D190: billing in loam-platform). Source: the owner's draft "CPU-Time Serverless Runtime: Consolidated Plan" v2 (2026-09-28). On 2026-09-29 the owner approved ten changes to that draft in conversation. This document is built on those changes, and they override the draft wherever the two differ. They are decisions D170–D179, marked approved in conversation 2026-09-29. D180–D188 are this document's own proposals and the parts of the draft that the changes left untouched; the owner has not yet ruled on them. D189 and D190 are owner decisions made on 2026-09-29, after the draft. The deployment and the Clever Cloud evaluation are in the companion document, §25. Amended 2026-10-01 by the owner's "Loams Serverless Runtime — Consolidated Plan" v1 (2026-09-30), folded in by §34: the Runner trait (D375) and usage from external runners (D376), §16 below; both proposed. Amended 2026-10-02 by §38 (D440, D441, D444, proposed): the trait now lives in §16, KnativeRunner runs the http-port contract on Knative Serving, no meter runs in this repository, and the Cloudflare runner moved to loam-platform.

Markers: (verify) means the claim was not checked against a primary source, or was checked only against a secondary one; the task that depends on it resolves it first. (estimate) means computed, not measured. (draft) means the figure comes from the owner's draft and was not re-checked here. Every license, release and pricing claim was read on 2026-09-29 from the source named in §15.

Numbering: main ends at D147 and Q44. Doc 23 (Neon and WeSQL) is being written at the same time on another branch and will take numbers after D147. This document starts at D170, a gap of about 20, and names its questions Q-RT-n so that nothing collides.

1. SummaryCopy Anchor Link

2. Goals and non-goalsCopy Anchor Link

2.1 GoalsCopy Anchor Link

• Waiting costs no CPU. An agent that spends 10 ms computing and 20 s waiting on a model is billed for 10 ms of CPU.
• Functions run next to Loams's data. A function reaches retrieval, Live, durable promises and streams over a loopback or node-local gRPC surface, not the public internet.
• Existing code runs unchanged. Hono apps and the output of the Cloudflare Workers framework adapters run on workerd without a Loams-specific port. Resonate SDK code runs as it does against any Resonate server.
• One deployment path. The same Git repository and charts deploy a laptop k3d cluster, a self-hosted cluster on RustFS and Loams cloud (§25 §6).

2.2 Non-goalsCopy Anchor Link

• A Vercel or Netlify clone (D170). There are no preview-deploy workflows, image optimization or edge-network CDN. Frontends get static hosting and the workerd preset.
• Transparent suspension of arbitrary code (D173). A Node or Python process waiting on a socket is not snapshotted. Only Resonate SDK code is evicted.
• Microsecond cold starts from VM snapshots in F1 (D174).
• A Loams implementation of Cloudflare's product bindings. Loams provides KV and R2-shaped bindings over its own storage (§4.2); D1, Queues, Analytics Engine and Hyperdrive are out of scope until someone asks.

3. ArchitectureCopy Anchor Link

            client ── HTTP/1.1·2·3, gRPC, WS/SSE
                               │
                     ┌─────────▼─────────┐
                     │  Envoy (edge, L7) │  TLS, HTTP/3, rate limits
                     └─────────┬─────────┘
                     ┌─────────▼─────────┐
                     │ loams-gateway (Rust)│  route → (tenant, function, version)
                     │ CloudEvents 1.0   │  admission, quotas, placement
                     └───┬──────────┬────┘
            ┌────────────▼──┐   ┌───▼────────────────┐
            │ node runtime  │   │ node runtime       │  one per node (DaemonSet)
            │ supervisor    │   │ supervisor         │
            │  ├ workerd/tenant (gVisor|seccomp)     │  T0  JS
            │  ├ wasmtime host (in-process, fuel)    │  T1  Wasm components
            │  └ runsc sandbox (Bun/Node/native)     │  T2  F2
            └──────┬────────┘   └─────┬──────────────┘
                   │ loopback gRPC (Dapr API subset + Loams APIs), sandbox token
            ┌──────▼──────────────────────────────────┐
            │ loams-dapr (Rust): tenant identity, secrets, metrics hooks, Dapr API → Loams │
            └──────┬───────────────┬──────────────┬───┘
         Resonate (durable)   Loams (retrieval, streams, Live)   shared daprd (long tail)
                   │               │
                  TiKV (PD+TiKV) ──┴── object store (RustFS by default; S3/Cellar providers)

3.1 What exists today, and what does notCopy Anchor Link

The draft says that "a Rust gRPC server translating the Dapr API to the internal streams gRPC already exists". The repository shows something narrower:

• crates/loams-stream-grpc is a native tonic service, loams.stream.v1.StreamService with a single Produce RPC (proto/loams/stream/v1/stream.proto). It is not the Dapr API.
• deploy/dapr/edge (loams-trigger-edge) is a Rust Dapr app. It uses the dapr 0.19 crate as a client of a Go daprd sidecar, receives pub/sub CloudEvents from Kafka, agent topics and webhooks, and calls StreamService.Produce through Dapr's gRPC proxy. Its init check refuses to start unless the Dapr Workflow APIs are denied, because Resonate owns durable execution.
• Both exist only as uncommitted files on the design-neon-wesql working tree, not on main.

A Rust server that implements Dapr's own gRPC service (dapr.proto.runtime.v1.Dapr), which the draft calls "the Dapr API in Rust", does not exist yet. F1 builds it (§6). It is called loams-dapr here; the name is open (Q-RT-1).

3.2 ComponentsCopy Anchor Link

4. Tiers and app contracts (D171, D172, D174, D181)Copy Anchor Link

4.1 TiersCopy Anchor Link

Why workerd rather than rquickjs (D171). With rquickjs, Loams would write and maintain the Web platform itself: fetch, streams, crypto.subtle, URL, TextEncoder, the nodejs_compat surface and more. The frameworks' Cloudflare adapters already target workerd's API, so it runs their output unchanged. workerd's README is explicit about the cost:

"WARNING: workerd is not a hardened sandbox … workerd on its own does not contain suitable defense-in-depth against the possibility of implementation bugs. When using workerd to run possibly-malicious code, you must run it inside an appropriate secure sandbox, such as a virtual machine." (cloudflare/workerd README.md, read 2026-09-29)

So isolates are never shared across tenants. Each tenant gets its own workerd process inside its own sandbox, and isolates separate one tenant's functions and versions only. workerd's open-source config (src/workerd/server/workerd.capnp) has no per-request CPU limit, which is why metering and limits act on the process (D175).

Loams Live keeps QuickJS for now. D120 (rquickjs in R1 for Live's deterministic functions) is not changed by this document. Live needs a deterministic Date.now() and Math.random() and one runtime per (node, app, deployment), which is a different problem. Q35 gains workerd as a candidate.

4.2 Bindings on workerdCopy Anchor Link

workerd's kvNamespace and r2Bucket bindings are turned into HTTP requests to a named service (workerd.capnp, lines 449–456). Loams implements those services in the node supervisor over Loams storage. KV maps to a Loams Live table or a TiKV keyspace, and R2 maps to the tenant's prefix in the object store. Durable Objects use workerd's localDisk storage (durableObjectStorage) only in dev; in clusters they are out of scope for F1 (Q-RT-4). A wrapped or service binding exposes loams-dapr and the Loams APIs to the function as env.LOAMS.

4.3 App contracts and frameworksCopy Anchor Link

Cloudflare publishes Workers guides for Astro, React Router, Next.js (OpenNext), Vue, SvelteKit, TanStack Start, Nuxt, Hono and others (developers.cloudflare.com/workers/framework-guides/web-apps). Those adapters build for Cloudflare's hosted runtime through wrangler. Loams takes their bundle and writes its own workerd capnp config. The compatibility gaps between hosted Workers and open-source workerd are a spike item (Q-RT-3).

5. Dapr surface (D182, D183)Copy Anchor Link

loams-dapr implements the subset of dapr.proto.runtime.v1.Dapr that maps onto Loams:

Tenant identity (D182). Every call to loams-dapr carries one of two things:

1. an mTLS client certificate with a SPIFFE ID (spiffe://<trust-domain>/tenant/<org>/ns/<ns>/fn/<fn>), for T2 and system components; or
2. a sandbox token, a Biscuit minted by the node supervisor for the invocation. Its authority block names the org, namespace, function, version and invocation id and carries a short expiry. The supervisor attenuates it with each call's allowed operations before passing it into the isolate or component (§25 §4).

loams-dapr derives the namespace from the credential, never from a request field, which is the rule §21 §5.2 already sets for the durable dispatcher. It then asks the Authorizer (OpenFGA, D66/D67) and emits the metering hooks of §7 (its own call metrics; it records no meter events, D200). The long tail (D183) is one shared daprd per cluster, running its components with Dapr's own scoping. loams-dapr forwards binding calls to it after the tenant check, so no Go sidecar runs per function.

5.1 Secrets from every cloud (D189)Copy Anchor Link

The owner decided on 2026-09-29 to adopt Dapr's secrets building block as the one path for tenant secrets. Loams then speaks to every store in dapr/components-contrib (Apache-2.0, v1.18.5, 2026-09-25) without writing a client for each. The components listed under secretstores/ in that repository, with the maturity given on docs.dapr.io's supported-stores page, are:

Every component implements the same Go interface (secretstores/secret_store.go): Init, GetSecret, BulkGetSecret and Features. The runtime exposes them as the gRPC calls GetSecret and GetBulkSecret in dapr/proto/runtime/v1/dapr.proto, and as GET /v1.0/secrets/{store}/{key} and /bulk over HTTP. A component is an ordinary Dapr Component (apiVersion: dapr.io/v1alpha1, spec.type, spec.version, spec.metadata, optional scopes), and its own credentials come from a secretKeyRef.

The practical path, while the Rust Dapr server is incomplete.

1. The shared Go daprd serves secrets, off the hot path (D183). Secrets are read at instance start and on cache miss, never once per request.
2. One component per tenant and store. Components are named t-<org>-<ns>-<store>, carry the tenant's own credentials (a secretKeyRef to a Kubernetes Secret owned by the tenant's resources, or the tenant's Vault role), and are generated by loams-operator from the tenant's settings in the ControlStore. Loams's own cloud credentials are never put in a tenant's component, and no two tenants share a component.
3. Loams enforces the scoping, not the caller. loams-dapr takes the tenant from the credential (§5), rewrites the caller's logical store name (aws, vault, …) to that tenant's component name, checks the key against the tenant's allow list and OpenFGA, and then calls daprd's GetSecret. Bulk reads are never forwarded to the shared daprd: GetBulkSecret returns every secret the component can see, which a check on one key does not authorize. loams-dapr answers a bulk request itself, with one GetSecret per key that is on the tenant's allow list and granted by OpenFGA, and drops every other key. A request that names another tenant's component cannot be expressed. With one shared daprd there is one Dapr app id, so Dapr's per-app secrets.scopes (storeName, defaultAccess, allowedSecrets, deniedSecrets) and component scopes cannot tell tenants apart. They are still set as a second, coarse layer: defaultAccess: deny for every store the platform itself does not need. Tenants that need Dapr-enforced separation too get a dedicated daprd whose app id is the tenant, with component scopes and secrets.scopes naming that id (Q-RT-15).
4. Adding a tenant's store must not restart the shared runtime. This depends on daprd reloading components when their resources change (verify: Dapr's component hot-reload feature and its maturity in v1.18). The fallback is a small pool of daprd replicas rolled one at a time.
5. Workload identity per tenant is limited. An AWS IRSA or Azure workload identity belongs to the daprd pod, not to a tenant, so tenant components use their own static credentials, Vault auth or cross-account role assumption where the component supports it (verify per component).

Cache. loams-dapr caches values per (tenant, store, key) for a TTL (default 60 s, capped by the tenant's setting) plus a short negative TTL. It drops a tenant's entries when that tenant is suspended or rotates a secret through the console, and zeroes values on eviction. The cache is per node and in memory only, never written to disk, the WAL or logs.

How each tier receives secrets. Secrets never enter the bundle or the manifest, only their names.

The loopback endpoint of a sandbox is bound to its own network namespace, so one tenant cannot reach another's bridge.

6. Suspend-on-await (D173)Copy Anchor Link

Only SDK code is evicted, because only SDK code is replayable. The Resonate SDKs record each step's result as a durable promise, so a re-invocation skips completed steps. Arbitrary JavaScript that holds a socket or a closure cannot be resumed without a memory snapshot, and T3 (D174) is deferred. The Resonate TypeScript SDK (Apache-2.0) has to run inside workerd. Whether it runs unchanged, or needs a fetch-based network and no Node built-ins, is a spike item (Q-RT-5).

Waking up. The supervisor is registered with Resonate as the worker for the tenant's function group. Resonate's http-poll transport (D141) delivers the task, and the supervisor starts an instance and re-invokes the function with the task. In clusters Resonate runs as its own Deployment on the TiKV store from the fork (loam/tikv-dapr, §22 §13b item 4). In loams dev it is embedded (§21).

7. Metering hooks (D175, D190)Copy Anchor Link

Billing and metering live in the private loam-platform repository (owner decision, 2026-09-29; D190). That covers the aggregation pipeline, meter events, rating, invoices and pricing. This open repository only exposes hooks that loam-platform, or a self-hoster's own tooling, reads:

The exact contract (metric families and labels, the cgroup layout and pod labels, the host-report socket and the tenant header) is §27 (D200–D202). The CPU sources behind those hooks are unchanged (D175): wasmtime fuel or epochs for T1; the per-tenant cgroup's cpu.stat for T0 (workerd, cross-checked with getrusage); the sandbox cgroup's cpu.stat for T2. eBPF (aya, sched_switch) comes last, as a cross-check, because a per-switch BPF map update taxes every tenant's hot path. Inside one workerd process, CPU is exact per tenant but only estimated per invocation (Q-RT-6). Runners outside Loams's nodes (Lambda, Workers) report through the runner host into the same contract, one reporter per invocation (§16, D376).

8. Storage and the data planeCopy Anchor Link

• Metadata: TiKV (D179, D124). Function versions, routes and the resident-pool directory live in a TiKV keyspace. PD and TiKV are deployed by TiDB Operator v2 (§25 §6). D-SC-16 dropped TiDB from the suite, and this runtime needs none.
• Bundles and static assets: the object store. RustFS by default (D178, D61), reached through ObjectStoreProvider. Durable writes use Loams's WAL group commit to S3 (§02).
• Cache: foyer (Apache-2.0, v0.22.6), a hybrid RAM and NVMe cache for bundles and hot static assets on each node, as in §04.
• io_uring only in the host data plane. Loams's own storage paths may use it. Tenant sandboxes are not given it: gVisor's io_uring support is limited and off by default (verify), and the seccomp profile for T0 denies it.

9. Cost model (checked 2026-09-29)Copy Anchor Link

Published prices.

Worked example: 100M requests a month, 10 ms CPU and 200 ms wall time per request.

What the numbers say. Cloudflare's CPU price is $0.072 per CPU-hour (3.6M CPU-ms per hour × $0.02 per million). That is only about 1.5× the EC2 floor at 100% utilization, and it is below Loams's cost at realistic utilization (40–60%, $0.078–0.118 per vCPU-hour, estimate). In Cloudflare's model the margin is in the request fee, not the CPU price. So Loams cannot win on CPU price alone. It wins on placement: a function next to the data does not pay egress, extra round trips or a separate database bill, and suspension (D173) means long-waiting agents hold no memory. This supports D170, and it makes the request price a pricing decision to settle with the owner (Q-RT-7).

10. SecurityCopy Anchor Link

• Per-tenant processes for T0 (D171), and gVisor for T0 and T2 where the node supports it. seccomp-bpf, user namespaces and cgroups are the fallback, and the fallback is reported in the node's status.
• No ambient credentials. Functions see only a sandbox token (D182) bound to the invocation and its expiry. An egress allowlist per tenant is enforced by the supervisor's network namespace (the same rule as D141's outbound allowlist).
• Spectre and timing. workerd's hosted defenses (Cloudflare's security-model post) are not all present in open-source workerd (verify). Tenant-per-process under gVisor is the answer, not isolate tricks.
• Resource limits per tier: memory (cgroup memory.max, Wasm memory limits), CPU per invocation (fuel/epoch for T1, a supervisor watchdog on the cgroup delta for T0 and T2), wall-clock per invocation (Q-RT-2).

11. Roadmap: track FCopy Anchor Link

Track F depends on the unified auth plan (Q30) for API keys and OpenFGA, on D72 (the stream API) and on the Resonate + TiKV validation in the forks (§22 §13b item 4). Like tracks R and D (D127, D145), it interleaves on the one-build machine.

12. Contradictions with earlier decisionsCopy Anchor Link

13. RisksCopy Anchor Link

14. Open questionsCopy Anchor Link

Open questions about the deployment and Clever Cloud are in §25 §8.

15. SourcesCopy Anchor Link

Read on 2026-09-29.

• The owner's draft "CPU-Time Serverless Runtime: Consolidated Plan" v2 (2026-09-28) and the owner's approved changes (conversation, 2026-09-29).
• Repository: crates/loams-stream-grpc/{Cargo.toml,proto/loams/stream/v1/stream.proto,src/lib.rs}, deploy/dapr/{README.md,edge/Cargo.toml,edge/src/main.rs} (uncommitted, design-neon-wesql working tree); §02, §04, §10 §1, §14, §18, §19 §5, §20, §21, §22 §13b; D47, D61, D66, D67, D72, D74, D111, D120, D124, D127, D139, D141, D145, D-SC-16; Q30, Q35.
• workerd: cloudflare/workerd README.md ("WARNING: workerd is not a hardened sandbox"), LICENSE (Apache-2.0), src/workerd/server/workerd.capnp (bindings kvNamespace, r2Bucket, wrapped, durableObjectStorage.localDisk; no CPU limit field); latest release v1.20260929.1 (2026-09-29).
• wasmtime: bytecodealliance/wasmtime LICENSE (Apache-2.0), release v49.0.1 (2026-09-24). Spin: spinframework/spin LICENSE (Apache-2.0), README.md (built on Wasmtime and the component model), crates/ (factors, trigger-http), release v4.1.0 (2026-08-26). wasmCloud: wasmCloud/wasmCloud LICENSE (Apache-2.0), README.md (CNCF Incubating; crates/wash-runtime "the embeddable Rust runtime … custom embedded hosts"; the runtime operator schedules over NATS), release v2.10.1 (2026-09-24).
• Kata: kata-containers/kata-containers src/runtime/virtcontainers/fc.go (PauseVM, SaveVM and ResumeVM return nil without acting), release 4.2.0; firecracker-containerd LICENSE Apache-2.0, last commit 2026-07-16, no releases.
• gVisor google/gvisor Apache-2.0, release-20260921.0. Dapr dapr/dapr Apache-2.0, v1.18.4. Resonate resonatehq/resonate Apache-2.0, v0.9.8; resonate-sdk-ts Apache-2.0. Hono MIT, v4.13.10. OpenNext Cloudflare MIT, 1.20.6. foyer Apache-2.0, v0.22.6. aya Apache-2.0/MIT. Envoy Apache-2.0, v1.39.1.
• Cloudflare framework guides: developers.cloudflare.com/workers/framework-guides/web-apps.
• Dapr secrets: dapr/components-contrib secretstores/ (directory listing; secret_store.go), release v1.18.5; dapr/dapr dapr/proto/runtime/v1/dapr.proto (rpc GetSecret, rpc GetBulkSecret); docs.dapr.io/reference/components-reference/supported-secret-stores (status per store); docs.dapr.io/developing-applications/building-blocks/secrets/secrets-scopes (secrets.scopes).
• Pricing: developers.cloudflare.com/workers/platform/pricing; vercel.com/docs/functions/usage-and-pricing (updated 2026-06-16); aws.amazon.com/lambda/pricing.

16. Amendments from the consolidated plan (2026-10-01; D375, D376)Copy Anchor Link

The owner's "Loams Serverless Runtime — Consolidated Plan" v1 (2026-09-30) restates this document's premise and adds runners outside Loams's nodes. The full reconciliation was §34; since the owner's ruling of 2026-10-02 (§38 D440) the protocol gateway and the Cloudflare runner are commercial components in loam-platform, and §34 is a stub. The Runner trait therefore lives here.

The draft's corrections, checked.

Runners (D375). §3's architecture is one Runner among several: the node supervisor and its tiers are SupervisorRunner, the default and the only runner with D170's placement next to the data. KnativeRunner (§38 D441) runs the http-port contract on Knative Serving in self-hosted clusters. LambdaRunner (Rust, arm64, provided.al2023) and, on demand, Cloud Run and Container Apps runners (Q367) are options for burst and BYOC. Runners outside this repository (the commercial Cloudflare runner in loam-platform) implement the same trait as RunnerKind::External. The trait is built by RN1; SupervisorRunner is built with F1. External runners run no Dapr (D183 is unchanged inside Loams's clusters).

// crates/loams-runner/src/lib.rs (RN1)
#[async_trait]
pub trait Runner: Send + Sync + fmt::Debug + 'static {
    fn kind(&self) -> RunnerKind;                                   // Supervisor, Process, Lambda, Knative, …
    fn capabilities(&self) -> &RunnerCapabilities;                  // contracts (fetch, http-port), limits, suspend support
    async fn deploy(&self, cx: &TenantCx, artifact: &Artifact) -> Result<Deployment, RunnerError>; // idempotent by digest
    async fn invoke(&self, cx: &InvocationCx, dep: &DeploymentRef, req: InvokeRequest) -> Result<InvokeResponse, RunnerError>;
    async fn undeploy(&self, cx: &TenantCx, dep: &DeploymentRef) -> Result<(), RunnerError>;
    async fn health(&self) -> RunnerHealth;
}
pub struct InvokeResponse { pub response: http::Response<Bytes>, pub usage: Option<Usage> } // None: the runner's usage reaches the hooks another way

Placement. D170's advantage is placement next to the data; a function on Lambda loses it and pays the round trips and egress. External runners are for burst capacity and BYOC accounts that want their own cloud bill, not the default.

Usage (D376). For external runners the gateway process that invoked the runner reports each invocation on /run/loams/meter.sock from the runner's measurement (Lambda: the bootstrap's getrusage delta, capped by the billed duration, Q366). These are hooks only: nothing in this repository aggregates, rates or bills them (§38 D444). The supervisor keeps reporting its own tiers (§7). loams.meter.v1.Invocation gains additive fields for the runner, the region, the provider's billed duration, compile CPU and overhead CPU (§27 §3.6).

Track F. F1 is unchanged. RN1 adds loams-meter (the host-report emitter of §27 §3.3, which F1's supervisor then uses), loams-runner, ProcessRunner and LambdaRunner; it does not build the supervisor.

Knative (2026-10-02, §38 D441). When knative.enabled, the http-port contract (T2) runs on Knative Serving through KnativeRunner, which takes over F2's pod scheduling; F2 keeps the gVisor node setup and the gvisor RuntimeClass. T0 and T1 stay on the supervisor.