Skip to main content
Put Lasso RPC Core in front of the providers you already use, then watch it route and fail over between them. Core picks each upstream from live health and recent latency, and fails replay-safe reads over within the request deadline. For a hosted pool, use Lasso Cloud custom profiles. This guide runs the released Core container locally.

​
Start the container

Install the selected release using the commands in Docker deployment. Confirm http://localhost:4000/api/health responds, then make an upstream-backed request from the quickstart to check that a provider answers.

​
Add your providers

Follow Docker deployment: custom profiles and credentials to mount a profiles/ directory. Keep its valid public.yml. Save the following as profiles/my-app.yml. Replace every environment variable with a credential-bearing URL from a provider or node you control. Each chain needs providers that actually serve that chain.
Store the variables in the private .env file used by Compose. Do not commit provider credentials. Unresolved variables reject the configuration. Validate chain identity and the methods your app needs against each upstream, and pick providers that don’t share a failure domain. See provider configuration for declared capabilities and provider selection for eligibility. After adding the mounted file or changing .env, recreate the container:
For later YAML-only edits, use the configuration reload. Check its result before shifting application traffic.

​
Exercise each route

Send an upstream-backed read through each chain. In the released Core version, fastest uses qualified recent latency evidence from client requests across methods for each provider and transport; the default route is load-balanced. Neither strategy promises that one provider always wins.
Check the response result and lasso_meta for each chain. The metadata identifies selection candidates, recorded attempts, and the executed channel when available. A candidate is not proof of a dispatch. See request metadata for the released field contract and a failover example.

​
Test a provider failure

In a non-production trial, interrupt one upstream that you control while you send replay-safe reads through the profile. Compare successful responses, errors, p95/p99 latency, head freshness, and attempted_channels before and during the fault. Then restore it and check recovery. Lasso can try another eligible provider within its deadline and dispatch budget; it cannot recover if the remaining pool is unavailable, over quota, or does not support the request. Signed transactions and other unsafe work have different replay rules in the method contract. Keep the original provider route available for rollback while you compare the same application traffic. Before exposing the container to clients, apply the network and authentication guidance: Core does not provide inbound API-key authentication or per-client RPC quotas.