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, and default_ttl, which collectively set how checkpoints expire.
  • serde (Agent server 0.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.

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.

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.

Connect these docs to Claude, VSCode, and more via MCP for real-time answers.