Documentation Edit this page

Lambda Server

Part of the LambdaServer project.

The managed LambdaServer deployment registers, invokes, and observes JVM functions without requiring callers to provision a process or container. Its authenticated HTTPS management interface runs separately from the url:// execution ServiceServer so the browser-facing WUI can scale and deploy independently while all function state and execution remain behind url://lambdaserver/.

Routes

Functions and invocations are also addressable at url://lambdaserver/functions/{functionId} and url://lambdaserver/invocations/{invocationId}.

Production architecture

Browser or HTTPS API client
          |
          | protected API calls carry mTLS / W3Wallet-derived proxy identity headers
          v
LambdaServerWui (Cloud Run)
          |
          | LambdaApiClient UrlLambdaService
          v
url://lambdaserver/
          |
LambdaServer (ContainerNursery, lazy-start + keep-warm)
          |
LambdaEmbedded FunctionManager
          |
/root/lambdaserver-workdir

The production ServiceServer uses LambdaEmbedded's local FunctionManager mode and stores its catalog, function JARs, and invocation records under /root/lambdaserver-workdir. LambdaStore-backed FunctionExecutor is supported by the project but is not the storage mode of this deployment.

W3Wallet capability and spend enforcement in the ServiceServer is opt-in. The current managed ServiceServer is started without the enforcement flags, so registration and invocation retain the legacy open RPC behavior; authentication for the hosted browser/API surface is enforced at the WUI ingress. Enabling ServiceServer enforcement is an operator change that also requires explicit trust roots and a provisioned AssetPools allowance/database.

Registration and execution

The WUI accepts three function sources: an uploaded JAR, a Maven coordinate resolved from configured repositories, or a Git repository cloned and built before analysis. Each path presents the discovered public methods to the caller and then registers the chosen class, method, parameter types/names, async mode, and JAR bytes through the same LambdaService contract.

Synchronous invocations return their result in the request. Asynchronous invocations return an invocation ID and are polled until the durable record reaches COMPLETED or FAILED. The ServiceServer exposes bounded newest-first history through listInvocations, including start/end timestamps, duration, status, and full failure text.

ContainerNursery service

• Route key: url:lambdaserver:
• Runtime type: danger_jarfile
• Arguments: --dir=/root/lambdaserver-workdir
• Warm policy: lazy-started and kept warm for 300 seconds after activity
• State: /root/lambdaserver-workdir must survive JAR upgrades and service restarts

Deploy the LambdaServer fat JAR through the ContainerNursery management API/CLI and restart only this route. Do not replace or clear the working directory during deployment: it contains the managed function catalog, uploaded artifacts, and invocation history.

Cloud Run WUI

ContainerNursery configures two HTTPS facade routes, one for the apex domain and one for www. Both use the cloudrunjar provider, the /root/ContainerNursery/apps/lambdawui.jar image, the www-lambdaserver-wasmserver Cloud Run service in us-central1, a 300-second warm period, and url://lambdaserver/ as a declared cold-start dependency. The WUI connects to that service with the matched LambdaApiClient/UrlResolver/UrlProtocol dependency stack. The ContainerNursery URL route and Cloud Run WUI can be upgraded independently, but the WUI client artifact must remain ABI-compatible with the ServiceServer's published SJVM client and resolver stack.

Protected API endpoints require an identity header supplied by the authenticated ingress:

• X-Client-Cert-Hash for client-certificate authentication
• X-W3Wallet-Daemon-Url for the W3Wallet browser-extension path

GET /api/config is an unauthenticated basic process-reachability probe. GET /api/functions requires one of the identity headers above and is the stronger integration probe because it traverses the WUI, LambdaApiClient, UrlResolver, and the live url://lambdaserver/ ServiceServer; an HTTP 500 with NoSuchMethodError indicates a client/resolver ABI mismatch rather than a ServiceServer outage.

Health checks

The LambdaServer ProductionHealth check validates both deployed boundaries:

1. The WUI returns HTTP 200 and the expected page title.
2. A real url://lambdaserver/ RPC returns bounded invocation history.
3. The check reports RPC latency, recent invocation count/failures, maximum recent duration, and full details for each recent failure. The registered check is intentionally read-only. Any separate mutating or cold-start acceptance check must use a dedicated canary function rather than invoking an existing production callback, because registered callbacks may have real external side effects.

Operational verification

After a ServiceServer or WUI upgrade:

1. Confirm the ContainerNursery route is healthy and url://lambdaserver/ is discoverable.
2. Confirm GET /api/config and authenticated GET /api/functions return HTTP 200.
3. If the release changes registration, use disposable dedicated canaries from uploaded-JAR, Maven, and built-from-Git sources; invoke both sync and async paths; verify the resulting invocation records.
4. During an approved maintenance test, stop the LambdaServer route, invoke the dedicated canary through the WUI, and record time to the first successful result to measure the true lazy-start budget.
5. Execute the registered ProductionHealth check and inspect its messages, not only the CLI's final status line.

Related services

• Lambda Store — optional remote persistence supported by LambdaEmbedded, but not used by this deployment
• Production Health — schedules and presents the LambdaServer health-check results
• ContainerNursery — hosts the url://lambdaserver/ ServiceServer route