Skip to main content
LangGraph apps usually fit the Agent Deployment service shape: a process starts an HTTP server, keeps graph state in your checkpointer, and accepts requests from your application. Use Agent Deployments when the LangGraph server should be a named, operated process with logs, status, a service instance, and a backing sandbox.

​
Deploy As A Service

You must bind the server to 0.0.0.0 so the Nullspace service proxy can reach it. 
name = "langgraph-service"
mode = "service"
template = "base"
workdir = "/workspace/project"
install = "python -m pip install -e ."
entrypoint = "python -m uvicorn src.server:app --host 0.0.0.0 --port 8000"

[service]
port = 8000
readiness = { type = "http", path = "/health", timeout_seconds = 30 }

[permissions]
public_url = true
Set permissions.public_url = true only when callers outside the sandbox need a public endpoint. 
nullspace agent deploy .
nullspace agent url langgraph-service \
  --env OPENAI_API_KEY="$OPENAI_API_KEY"

nullspace agent status langgraph-service --service adsvc_123
nullspace agent logs langgraph-service --service adsvc_123
See the LangGraph service example for a complete project.

​
State Boundary

LangGraph thread IDs and checkpoints remain framework-owned. Store checkpoints in your app database, checkpointer storage, or a mounted volume. Pass thread IDs through your request/session layer instead of treating Nullspace run IDs or service IDs as LangGraph thread IDs. Nullspace owns the deployment version, service instance, backing sandbox, logs, public URL metadata, and cleanup.

​
Local Tool Pattern

If your LangChain or LangGraph app should call Nullspace only for occasional isolated command execution, keep the framework process in your app and expose a typed sandbox tool instead. See LangChain for that pattern.