# 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](/lakeshore/lifecycle.md).

## 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    |