Deploy from Claude Code: a practical Lizard workflow

Claude Code can deploy an application by using a hosting provider's tools in your development environment. With Lizard, the agent can inspect the project, use the Lizard CLI to deploy, configure dependencies and check the live service. The host runs the application after the coding session ends.

The useful result is a working user flow at a live URL, not just a command that exits successfully. This guide checks the Lizard CLI and linked documentation as of 9 September 2026.

Give the agent the right context

Start with a repository that builds and has a production start command. Identify the workspace and project that should own it, whether it needs a database or worker, and whether the deploy creates a test copy or changes an existing service.

Install the CLI and read its version-matched instructions:

npm install -g @lizard-build/cli
lizard skills get core --json
lizard status --json

If authentication is needed, use lizard login and finish the browser sign-in. For the reusable agent instructions, follow the Lizard Skill repository. Claude Code's own overview describes how it works with a codebase and tools.

The agent should inspect existing configuration before adding anything. A runtime version, Dockerfile or start command already in the project is better evidence than a command guessed from the framework name.

A prompt that defines the deployment task

Give the agent a bounded instruction such as:

Deploy this repository to the existing Lizard project my-project as a test service. Read the current Lizard CLI guide and inspect the build and start commands first. Use the GitHub source if the repository has an accessible GitHub remote. Configure the services this app actually needs. Verify the live URL, logs and one real application flow. Report the deployed revision and any check that failed.

Replace the project and environment with the intended target. State explicitly when a production service or domain should change. The agent should not infer a production database migration from a request to publish a test copy.

Choose Git deployment or source upload

Use the repository's GitHub integration when you want later commits to trigger deployments. The GitHub deployment guide covers connection and service setup. Check the tracked branch and root directory for a monorepo.

For a local project without a suitable GitHub remote, source upload is available. After selecting the right workspace, a new example project and service can use:

lizard init --name my-project
lizard add --service api
lizard up --service api

These names are examples. For an existing project, confirm the current link with lizard status --json and select the existing service. Do not create another project or switch a Git-backed service to upload merely to avoid reading its settings.

Lizard performs the hosted build. Depending on the project and service configuration, it can use the repository's Dockerfile or generate one through the supported build path. Read the deployment docs and keep the settings in the configuration reference repeatable.

Connect the database deliberately

Creating Managed Postgres does not prove the application can reach it. The application must read the connection variable you set. For a project with a service named api and its first PostgreSQL add-on named postgres, the reference is:

lizard add postgres
lizard secrets set 'DATABASE_URL=${{postgres.DATABASE_URL}}' --service api

Use the add-on's actual name if it differs. Configure each consumer service, including workers, with the variables it needs. Run migrations as a controlled release step and confirm an application read and write against the intended database. See variable references and Managed Postgres.

For uploads, choose storage that survives the lifecycle your app needs. For a worker, check that it can reach the broker and handle restarts. Avoid treating the successful creation of resources as a completed application setup.

Check the result from the outside

Use structured output for diagnostics:

lizard status --json
lizard logs --service api --json
lizard logs --service api --build --json
lizard metrics --service api --json

Then fetch the live URL and exercise a real flow. For a small API, that might be authentication followed by a write and read. For a frontend, check a route reached directly by URL as well as through client-side navigation.

If deployment fails, use the reported error to choose the next check:

An agent should report an unresolved error rather than declare success from the build log. The Python hosting guide gives examples of start-command problems.

Understand the cost of the workflow

Your coding subscription and hosting bill pay for different parts of the work. Lizard's pricing page describes plans and resource charges. A test service, database or sandbox can continue consuming resources after the coding session ends.

Set resource limits and review use. Stop or remove temporary resources when they are no longer needed through your normal approval process. Do not assume that closing Claude Code stops an application that has already deployed.

FAQ

Does Claude Code host the app? The deployment target does. Claude Code uses tools to prepare and deploy the code; the hosting provider runs the resulting application.

Can I deploy an existing GitHub repository? Yes, if Lizard can access it. Configure the repository, branch and service through the Git deployment workflow, then verify the deployed revision.

Do databases connect automatically? Provision the database, configure the variable the application reads, and test the connection. Those are separate checks.

Can the same workflow work with another coding agent? An agent that can use the required tools can follow the same deployment checks. Read its own permission and tool setup rather than assuming every environment behaves like Claude Code.

How do I know the deployment is complete? Confirm the live URL, expected revision, healthy process and meaningful application behaviour. A successful build alone is not enough.