Skip to main content
LangGraph CLI is a command-line tool for building and running the Agent Server locally. The resulting server exposes all API endpoints for runs, threads, assistants, etc., and includes supporting services such as a managed database for checkpointing and storage.

Installation

  1. Ensure Docker is installed (e.g., docker --version).
  2. Install the CLI:
  3. 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.

Examples

Basic configuration

Using Wolfi base images

You can specify the Linux distribution for your base image using the image_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 your langgraph.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 put time using the index parameter
Common model dimensions
  • openai:text-embedding-3-large: 3072
  • openai:text-embedding-3-small: 1536
  • openai:text-embedding-ada-002: 1536
  • cohere:embed-english-v3.0: 1024
  • cohere:embed-english-light-v3.0: 384
  • cohere:embed-multilingual-v3.0: 1024
  • cohere: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:
The 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

See the authentication conceptual guide for details, and the setting up custom authentication guide for a practical walk through of the process.

Configuring store item Time-to-Live

You can configure default data expiration for items/memories in the BaseStore using the store.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: If true (the default), accessing an item via get or search resets its expiration timer. Set to false to 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.
Here is an example enabling a 7-day TTL (10080 minutes), refreshing on reads, and sweeping every hour:

Configuring checkpoint Time-to-Live

You can configure the time-to-live (TTL) for checkpoints using the checkpointer 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: Includes strategy, sweep_interval_minutes, default_ttl, and sweep_limit (Agent server v0.8+), which collectively set how checkpoints expire.
  • serde (Agent server v0.5+) : Lets you control deserialization behavior for checkpoint payloads.
Here’s an example setting a default TTL of 30 days (43200 minutes):
In this example, checkpoints older than 30 days will be deleted, and the check runs every 10 minutes.

Configuring checkpointer serde

The checkpointer.serde object shapes deserialization:
  • allowed_json_modules defines 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 to true to allow any module to be deserialized.
  • pickle_fallback: Whether to fall back to pickle deserialization when JSON decoding fails.

Customizing HTTP middleware and headers

The http 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 through http.app.
  • configurable_headers / logging_headers: Each accepts an object with optional includes and excludes arrays; wildcards are supported and exclusions run before inclusions.
  • cors: Customize your server’s CORS (Cross-Origin Resource Sharing) configuration. Example langgraph.json file for configuring CORS:
    Customizing your server’s CORS configuration will override the functionality of setting the CORS_ALLOW_ORIGINS environment variable.

Configuring webhooks

You can configure custom headers and URL restrictions for outbound webhook requests:
See Use webhooks for details on header configuration, environment variable templating, and URL restrictions.

Pinning API version

(Added in v0.3.7)You can pin the API version of the Agent Server by using the api_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 the http 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:
Setting 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
The /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
The base command for the LangGraph CLI is langgraph.

dev

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.
Currently, the CLI only supports Python >= 3.11.
If you need more information on when to use langgraph dev vs langgraph up, refer to the Local development & testing guide for a detailed comparison.
InstallationThis command requires the “inmem” extra to be installed:
Usage
Options

build

Build LangSmith API server Docker image.Usage
Options*Only supported for JS deployments, will have no impact on Python deployments.

deploy

This command is in beta and under active development. Expect frequent updates and improvements.
Build and deploy a LangGraph image directly to LangSmith Deployments. This command builds a Docker image locally, pushes it to a managed registry, and creates or updates a deployment—all in a single step. If Docker is not installed, it triggers a remote build.Prerequisites
  • 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.
Usage
This command also accepts all 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.Usage
Options

deploy revisions

[Beta] Manage deployment revisions.Usage
OptionsCommands

deploy revisions list

[Beta] List revisions for a LangSmith Deployment.Use deploy list to list deployment IDs.Usage
Options

deploy delete

Delete a LangSmith Deployment.Use deploy list to find the deployment ID to delete.Usage
Options

deploy logs

Fetch LangSmith Deployment logs. Use deploy for agent runtime logs, or build for remote build logs.Usage
Options

up

Start LangGraph API server. For local testing, requires a LangSmith API key with access to LangSmith. Requires a license key for production use.
If you need more information on when to use langgraph dev vs langgraph up, refer to the Local development & testing guide for a detailed comparison.
Usage
Options

dockerfile

Generate a Dockerfile for building a LangSmith API server Docker image.Usage
OptionsExample:
This generates a Dockerfile that looks similar to:
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.