DreamLake
  1. Get Started
  2. CLI
  3. Python
  4. Nymph
  5. API
  6. Admin

CLI examples

Shell-by-shell walkthroughs of common operator tasks, grouped by what you're trying to do. Start with the auth page — the rest assume the shell setup it describes.

PageCovers
Auth + setupOne-time login, shell environment, $D seeding
Providers + discoverRegister cloud, SSH, SLURM, Kube targets; the local discovery helpers
Queues + jobsNamed work queues and inspecting invocations
Daemons + exec/runWorker daemons, compose, and one-off command execution
Storage, code, mountsS3 storage entries, code archives, mount declarations
Secrets, modes, tunnels, config, nymphThe long tail of management commands

If you want a guided narrative instead, see the CLI happy paths.

Conventions used across these pages

  • Names for providers, secrets, modes, tunnels, mounts, storage entries, and queues all validate against ^[a-z0-9][a-z0-9-]*$.
  • Every action calls process.exit(rc). 2 is the conventional "bad usage / not configured" code and 1 is the failure code, so these blocks are safe under set -e.
  • --json is available on most read commands and is the intended scripting surface; the table output is for humans and not stable.

What's not on these pages

  • Provider-driven dispatch from Python — the @dls.udf decorator, modes, capacity matching — lives on /python-sdk. The CLI's role there is to register the targets; the Python API runs the jobs.
  • Lower-level daemon internals — capability publishing, hibernate semantics, OTA self-replace — are documented at /nymph/daemons and /nymph/protocol.
  • The dreamlake group — a separate data plane with its own servers, its own credential store (~/.dreamlake/), and its own connection flags. It is not covered by this cookbook.

Read next