LILYLILYDOCS
Docs/Troubleshooting

Troubleshooting

The most common ways things go sideways, and how to undo each one.

Run lly doctor first. It checks the binary, the plugin directory, the runtime, and reachability of rc.lilylabs.io. Most of the failures below show up there as a single red line before they ever bite a real workflow. See lly doctor for the full output reference.

Install and PATH

lly: command not found

The install script writes the binary to /usr/local/bin/lly. If your shell does not have that directory on PATH, the command will not resolve. Re-run the installer, then open a fresh shell.

reinstall
$ curl -sSL rc.lilylabs.io/install.sh | bash → fetching lly 1.4.0 (x86_64-linux) ✓ installed /usr/local/bin/lly append /usr/local/bin to PATH in ~/.bashrc if missing $ lly version lly 1.4.0 (rev a64d552, 2026-05-18)

lly doctor: rc.lilylabs.io unreachable

Corporate networks usually terminate egress at a proxy. The CLI honours the standard HTTPS_PROXY and HTTP_PROXY environment variables for every outbound request, including the install script and plugin downloads.

proxy
$ export HTTPS_PROXY=http://proxy.corp:3128 $ lly doctor ✓ binary lly 1.4.0 ✓ plugin path ~/.lly/plugins ✓ runtime wasmtime 22.0.0 ✓ rc.lilylabs.io reachable via proxy.corp:3128

Authentication

lly login cannot open a browser

On headless boxes, SSH sessions, and CI runners there is no browser to launch. Use --print-url to print the auth URL and open it manually from another machine. The WebSocket callback works across networks as long as your CLI host can reach auth.lilylabs.io.

headless login
$ lly login --print-url open this URL in any browser: https://auth.lilylabs.io/cli?code=7F2A-9KQ4 waiting for confirmation… ✓ signed in as leonnk5678@gmail.com

lly void deploy: 401 unauthorized

Access tokens are short-lived. After about a week of inactivity the cached credential in ~/.lly/credentials expires and every authenticated call returns 401. Re-run lly login. The CLI never refreshes tokens silently, by design.

Plugins

lly plugin install: signature mismatch

Each plugin manifest is signed at publish time. A mismatch almost always means the local manifest cache is stale and points at an old binary. Clear the cache and retry. If it persists past a fresh install, treat it as a real signature failure and report it.

stale cache
$ lly plugin install nextjs ✗ signature mismatch for nextjs@0.7.3 $ lly cache clean ✓ removed 142 MB from ~/.cache/lly $ lly plugin install nextjs ✓ installed nextjs 0.7.3 to ~/.lly/plugins/nextjs

Builds

lly nextjs void: out of memory

The Next.js plugin spawns an esbuild worker for client bundles and a Node helper for any 'use server' rewrite. Both inherit Node's default 1.7 GB heap. Large monorepos can blow past it during the import-graph walk. Bump the heap before running the build.

heap
$ export NODE_OPTIONS=--max-old-space-size=4096 $ lly nextjs void → discovered 84 routes, 19 'use client' boundaries → bundling hydrate entries via esbuild… ✓ wrote void.brick (6.2 MB) in 8.4s

Runtime and deploys

Live URL returns 503

The CAP fleet cold-starts a brick the first time a placement gets traffic. The initial WASM compile and module instantiation takes up to 30 seconds for large bricks. A 503 inside that window is expected. Wait, then tail logs to confirm the boot completed.

cold start
$ lly void deploy ./void.brick ✓ placed at https://lazy-fox.app.lilylabs.io $ lly void logs lazy-fox --follow 2026-06-04T10:14:02Z cap-7 instantiating module (6.2 MB)… 2026-06-04T10:14:18Z cap-7 ready, listening on :8080 2026-06-04T10:14:19Z GET / 200 14ms

Still stuck

Send the output of lly doctor, the exact command you ran, and the full error to support@lilylabs.io. Most tickets are answered the same day. For installation and connectivity questions, the lly doctor page documents every check the CLI performs at startup.