Installation
-
Ensure Docker is installed (e.g.,
docker --version). -
Install the CLI:
-
Verify the install
Quick commands
For JS, use
npx @langchain/langgraph-cli <command> (or langgraphjs if installed globally).
Configuration file
To build and run a valid application, the LangGraph CLI requires a JSON configuration file that follows this schema. It contains the following properties:The LangGraph CLI defaults to using the configuration file named langgraph.json in the current directory.
- Python
- JS
Examples
- Python
- JS
Basic configuration
Using Wolfi base images
You can specify the Linux distribution for your base image using theimage_distro field. Valid options are debian, wolfi, bookworm, or bullseye. Wolfi is the recommended option as it provides smaller and more secure images. This is available in langgraph-cli>=0.2.11.Adding semantic search to the store
All deployments come with a DB-backed BaseStore. Adding an “index” configuration to yourlanggraph.json will enable semantic search within the BaseStore of your deployment.The index.fields configuration determines which parts of your documents to embed:- If omitted or set to
["$"], the entire document will be embedded - To embed specific fields, use JSON path notation:
["metadata.title", "content.text"] - Documents missing specified fields will still be stored but won’t have embeddings for those fields
- You can still override which fields to embed on a specific item at
puttime using theindexparameter
Common model dimensions
openai:text-embedding-3-large: 3072openai:text-embedding-3-small: 1536openai:text-embedding-ada-002: 1536cohere:embed-english-v3.0: 1024cohere:embed-english-light-v3.0: 384cohere:embed-multilingual-v3.0: 1024cohere:embed-multilingual-light-v3.0: 384
Semantic search with a custom embedding function
If you want to use semantic search with a custom embedding function, you can pass a path to a custom embedding function:embed field in store configuration can reference a custom function that takes a list of strings and returns a list of embeddings. Example implementation:Adding custom authentication
Configuring store item Time-to-Live
You can configure default data expiration for items/memories in the BaseStore using thestore.ttl key. This determines how long items are retained after they are last accessed (with reads potentially refreshing the timer based on refresh_on_read). Note that these defaults can be overwritten on a per-call basis by modifying the corresponding arguments in get, search, etc.The ttl configuration is an object containing optional fields:refresh_on_read: Iftrue(the default), accessing an item viagetorsearchresets its expiration timer. Set tofalseto only refresh TTL on writes (put).default_ttl: The default lifespan of an item in minutes. Applies only to newly created items; existing items are not modified. If not set, items do not expire by default.sweep_interval_minutes: How frequently (in minutes) the system should run a background process to delete expired items. If not set, sweeping does not occur automatically.
Configuring checkpoint Time-to-Live
You can configure the time-to-live (TTL) for checkpoints using thecheckpointer key. This determines how long checkpoint data is retained before being automatically handled according to the specified strategy (e.g., deletion). Two optional sub-objects are supported:ttl: Includesstrategy,sweep_interval_minutes,default_ttl, andsweep_limit(Agent server v0.8+), which collectively set how checkpoints expire.serde(Agent server v0.5+) : Lets you control deserialization behavior for checkpoint payloads.
Configuring checkpointer serde
Thecheckpointer.serde object shapes deserialization:allowed_json_modulesdefines an allow list for custom Python objects you want the server to be able to deserialize from payloads saved in “json” mode. This is a list of[path, to, module, file, symbol]sequences. If omitted, only LangChain-safe defaults are allowed. You can unsafely set totrueto allow any module to be deserialized.pickle_fallback: Whether to fall back to pickle deserialization when JSON decoding fails.
Customizing HTTP middleware and headers
Thehttp block lets you fine-tune request handling:-
middleware_order: Choose"auth_first"to run authentication before your middleware, or"middleware_first"(default) to invert that order. -
enable_custom_route_auth: Extend authentication to routes you mount throughhttp.app. -
configurable_headers/logging_headers: Each accepts an object with optionalincludesandexcludesarrays; wildcards are supported and exclusions run before inclusions. -
cors: Customize your server’s CORS (Cross-Origin Resource Sharing) configuration. Examplelanggraph.jsonfile for configuring CORS:Customizing your server’s CORS configuration will override the functionality of setting theCORS_ALLOW_ORIGINSenvironment variable.
Configuring webhooks
You can configure custom headers and URL restrictions for outbound webhook requests:Pinning API version
(Added in v0.3.7)You can pin the API version of the Agent Server by using theapi_version key. This is useful if you want to ensure that your server uses a specific version of the API.
By default, builds in Cloud deployments use the latest stable version of the server. This can be pinned by setting the api_version key to a specific version.Disabling built-in routes
You can selectively disable groups of built-in HTTP routes using boolean flags in thehttp configuration block. This is useful for production deployments where you want to minimize the server’s exposed surface area.For example, to disable the system information and documentation routes:disable_meta to true disables the following routes:/— root health check/info— server version and configuration info/metrics— Prometheus and JSON metrics/docs— API documentation UI/openapi.json— OpenAPI specification
/ok health check endpoint remains available even when disable_meta is set, so orchestrators like Kubernetes can still perform liveness and readiness probes.Other route disable flags include disable_assistants, disable_runs, disable_threads, disable_store, and disable_ui. For MCP, A2A, and webhooks, see their respective guides: Disable MCP, Disable A2A, Disable webhooks.Commands
Usage- Python
- JS
The base command for the LangGraph CLI is
langgraph.dev
- Python
- JS
Run LangGraph API server in development mode with hot reloading and debugging capabilities. This lightweight server requires no Docker installation and is suitable for development and testing. State is persisted to a local directory.InstallationThis command requires the “inmem” extra to be installed:UsageOptions
Currently, the CLI only supports Python >= 3.11.
build
- Python
- JS
Build LangSmith API server Docker image.UsageOptions
*Only supported for JS deployments, will have no impact on Python deployments.
deploy
- Python
This command is in beta and under active development. Expect frequent updates and improvements.
- A LangSmith API key with access to Deployments.
- (Optional) Docker must be installed and the Docker daemon must be running for local builds. Not required for remote builds. Install Docker Desktop.
Works only with LangSmith Cloud.
langgraph build flags (--platform, -t, --pull, --no-pull, -c). For details, refer to langgraph build --help.OptionsExample
Deployments created through other methods (e.g., the LangSmith UI or GitHub integration) can also be updated with the
langgraph deploy command.deploy list
List LangSmith Deployments.Usagedeploy revisions
[Beta] Manage deployment revisions.UsageCommands
deploy revisions list
[Beta] List revisions for a LangSmith Deployment.Use deploy list to list deployment IDs.Usagedeploy delete
Delete a LangSmith Deployment.Use deploy list to find the deployment ID to delete.Usagedeploy logs
Fetch LangSmith Deployment logs. Use deploy for agent runtime logs, or build for remote build logs.Usageup
- Python
- JS
Start LangGraph API server. For local testing, requires a LangSmith API key with access to LangSmith. Requires a license key for production use.UsageOptions
dockerfile
- Python
- JS
Generate a Dockerfile for building a LangSmith API server Docker image.UsageOptionsThis generates a Dockerfile that looks similar to:
Example:
The
langgraph dockerfile command translates all the configuration in your langgraph.json file into Dockerfile commands. When using this command, you will have to re-run it whenever you update your langgraph.json file. Otherwise, your changes will not be reflected when you build or run the dockerfile.Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

