## Summary `--push-to` always builds (or retags a local `--image`) and pushes, even when the image already exists at the destination. That breaks CI/CD pipelines where the build/push step and the deploy step run in separate jobs: the deploy job has no local copy of the image to retag, and `--image` requires one (it runs `docker image inspect`, which needs the image present in the local Docker daemon). This adds `--image-uri`, which takes a full image reference already in a registry and deploys it directly via `source_revision_config.image_uri`, with no local Docker involvement at all: no inspect, no build, no tag, no push. It gets the same placement behavior as `--push-to` (`--listener-id`/`--k8s-namespace`, or auto-selecting the sole listener) and the same update-in-place semantics, since both produce an `external_docker` deployment and are interchangeable on the same deployment. `--image-uri` requires a digest (`repo@sha256:...`) and rejects empty/blank input. `--push-to` always resolves to a digest after pushing; `--image-uri` has no push step to resolve one from, so a mutable tag (or an unvalidated empty string) could let Kubernetes silently keep running a previously cached image while the CLI reports success. Implementation: `CustomerRegistrySource`'s image-acquisition step is split into two variants, `BuildAndPush` (the existing `--push-to`/`--image` flow, unchanged behavior) and `PublishedImage` (the new flag), so create/update/placement logic stays shared. Also reworded `_ensure_customer_registry_source`'s error, which previously mentioned only `--push-to` even though it's reachable from `--image-uri` too. ## Test plan - [x] `make format && make lint` clean in `libs/cli` - [x] Unit tests in `test_deploy_helpers.py` for `_select_source` selecting `PublishedImage` (by digest, trimmed), requiring no local Docker, carrying placement, and the mutual-exclusivity + validation errors (`--push-to`, `--image`, `--tag`, `--remote`, empty/blank input, missing digest) - [x] CLI-level tests in `test_deploy_command.py`: create and update an external deployment via `--image-uri` with zero Docker calls, listener auto-placement, rejecting a non-external existing deployment (now mentioning both flags), and the conflicting-flag cases end to end - [x] Full `libs/cli` suite: 524 passed, no regressions
LangGraph CLI
To help you ship LangGraph apps to production faster, check out LangSmith. LangSmith is a unified developer platform for building, testing, and monitoring LLM applications.
Quick Install
uv add langgraph-cli
🤔 What is this?
The LangGraph CLI is the official command-line interface for LangGraph. It provides tools to create, develop, build, and run LangGraph applications locally or in Docker.
📖 Documentation
For full documentation, see the LangGraph CLI reference. For conceptual guides and tutorials, see the LangGraph Docs.
For development mode with hot reloading:
uv add "langgraph-cli[inmem]"
Commands
langgraph new 🌱
Create a new LangGraph project from a template.
langgraph new [PATH] --template TEMPLATE_NAME
langgraph dev 🏃♀️
Run LangGraph API server in development mode with hot reloading.
langgraph dev [OPTIONS]
--host TEXT Host to bind to (default: 127.0.0.1)
--port INTEGER Port to bind to (default: 2024)
--no-reload Disable auto-reload
--debug-port INTEGER Enable remote debugging
--no-browser Skip opening browser window
-c, --config FILE Config file path (default: langgraph.json)
langgraph up 🚀
Launch LangGraph API server in Docker.
langgraph up [OPTIONS]
-p, --port INTEGER Port to expose (default: 8123)
--wait Wait for services to start
--watch Restart on file changes
--verbose Show detailed logs
-c, --config FILE Config file path
-d, --docker-compose Additional services file
langgraph build
Build a Docker image for your LangGraph application.
langgraph build -t IMAGE_TAG [OPTIONS]
--platform TEXT Target platforms (e.g., linux/amd64,linux/arm64)
--pull / --no-pull Use latest/local base image
-c, --config FILE Config file path
langgraph dockerfile
Generate a Dockerfile for custom deployments.
langgraph dockerfile SAVE_PATH [OPTIONS]
-c, --config FILE Config file path
Configuration
The CLI uses a langgraph.json configuration file with these key settings:
{
"dependencies": ["langchain_openai", "./your_package"],
"graphs": {
"my_graph": "./your_package/file.py:graph"
},
"env": "./.env",
"python_version": "3.11",
"pip_config_file": "./pip.conf",
"dockerfile_lines": []
}
Git dependencies should use credential-free URLs. The CLI conservatively scans direct langgraph.json dependencies, common Python package files, uv project and lock files, and common Node.js package and lock files for HTTP Git URLs with userinfo. This check is not exhaustive: generated Docker builds can copy other files, including nested requirement or constraint files, into image layers without scanning them. For private dependencies, provide short-lived credentials through your build environment's secret-backed Git credential helper. Do not store credentials in copied files such as langgraph.json or pip_config_file.
See the full documentation for detailed configuration options.
Development
To develop the CLI itself:
- Clone the repository
- Navigate to the CLI directory:
cd libs/cli - Install development dependencies:
uv sync - Make your changes to the CLI code
- Test your changes:
# Run CLI commands directly
uv run langgraph --help
# Or use the examples
cd examples
uv sync
uv run langgraph dev # or other commands
📕 Releases & Versioning
See our Releases and Versioning policies.
💁 Contributing
As an open-source project in a rapidly developing field, we are extremely open to contributions, whether it be in the form of a new feature, improved infrastructure, or better documentation.
For detailed information on how to contribute, see the Contributing Guide.