Lakeshore
Lakeshore runs your Python functions on machines that are not your laptop. You
decorate a function with @udf and call it; Lakeshore queues the invocation,
ships it to a worker, runs it, and hands the result back. You write Python — it
handles the scheduling, the transport, and the worker side.
You reach for Lakeshore when the work does not fit on the machine in front of you: a GPU job, a long sweep, or a fan-out of identical calls you want to run all at once. Nothing about the function has to change to move it off your laptop — the decorator is the only difference between a local call and a remote one.
The three layers
Lakeshore ships as three pieces, each deployed and upgraded on its own:
| Layer | What it is | What it does |
|---|---|---|
| Client | Python SDK (dreamlake-lakeshore) and the lakeshore CLI (@dreamlake/lakeshore) | Where you write @udf, and where an operator manages queues, providers, and daemons |
| Control plane | A single service that owns the authoritative state | Holds queues, workers, providers, and pending invocations; dispatches work |
| Runtime | The nymph daemon on each compute host | Long-polls the control plane and executes invocations next to your data |
The daemon connects outbound only, so a worker can sit behind a firewall, in a cluster, or on a machine you already own, and still take work. What it does between starting and taking that work — coming up, running its setup, declaring itself ready, and saying so on the way out — is the worker lifecycle.
Start here
Run a Python function through a local queue, then point the SDK at a service.
Host the control-plane server and create its first namespace and client login.
Add an existing service and inspect its queues, workers, and jobs.
Enroll an SSH-accessible machine, prepare credentials, and test tracked runs.
The first UDF type — sync, async, generator and async-generator bodies, scopes, key-based returns, and the registry payload each one produces.
The whole stack on one laptop — no cloud account, no release download, and a daemon you built yourself.
A queue is one model carrying both a scheduling surface and a launch policy, because queue depth is the autoscaling signal.
The provider types compute can be launched through, and which of them are finished.
Deep reference
This tab is orientation. The canonical, complete documentation for the SDK, the CLI, the daemon, and the control plane lives on its own site.
The full SDK reference — @udf, queues, invocations, dispatch, and payloads.
The lakeshore command — auth, queues and jobs, providers, daemons, and the
tui dashboard.
How a call becomes a queued invocation and lands on a remote worker.
The worker daemon — lifecycle, wire protocol, identity and key rotation, telemetry.
How it connects to DreamLake
| Piece | Where | Role |
|---|---|---|
| Control plane | api.lakeshore.dreamlake.ai | Queues invocations, tracks workers, brokers results |
| nymph daemon | Compute hosts, outbound-only | Executes invocations next to your data |
| Python SDK | dreamlake-lakeshore (PyPI) | @udf decorator, queues, invocation handles |
| CLI | @dreamlake/lakeshore (npm) | lakeshore tui, jobs, daemons, queue management |