By the Lizard (lizard.build) team. Our October 12 announcement describes hosting the code an agent builds as a separately running app container with its own HTTPS URL, beyond the sandbox lifecycle.
The current Lizard CLI reference says lizard up packages the working directory and forces upload source on the target service. Use it intentionally for local code. Review the upload contents and ignored files first; configuration should not depend on files accidentally omitted from the source.
For a GitHub-backed app, verify repository access, tracked branch and root directory. Connect the intended repository, configure the service before its first build, then use the documented GitHub deployment path. Update through a tracked-branch push with auto-deploy enabled or lizard redeploy --service api for the intended existing service. Do not use lizard up as a neutral GitHub update command.
Before either path, lizard status --json helps inspect the directory’s project context. Read lizard up --help --json for version-matched options. In an already authenticated, linked and configured project with an existing upload service named api, lizard up --service api is the deployment step; setup still precedes it.
One-command deployment assumes the account, project context and application configuration are ready. Do not assume secrets, dependencies or existing data transfer automatically. A persistent app container does not guarantee local filesystem durability across replacement or redeployment.
Original October 12 announcement. Read the current Lizard CLI reference, deployment command, GitHub source guide and storage and recovery guidance. Commands and docs checked October 12, 2026.
Responses
Join the conversation
Sign in to share your thoughts and interact with the author.
Sign In to Comment