LangGraph apps usually fit the Function service shape: a process starts an HTTP server, keeps graph state in your checkpointer, and accepts requests from your application. Use Functions when the LangGraph server should be a named, operated process with logs, status, a service instance, and a backing machine.

​
Deploy As A Service

You must bind the server to 0.0.0.0 so the Nullspace service proxy can reach it.
function.py
import nullspace

function = nullspace.Function(
    "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=nullspace.Service(
        port=8000,
        readiness={"type": "http", "path": "/health", "timeout_seconds": 30},
    ),
    policy=nullspace.Policy(public_url=True),
)
Set nullspace.Policy(public_url=True) only when callers outside the machine need a public endpoint. 
nullspace functions deploy
nullspace functions url langgraph-service \
  --env OPENAI_API_KEY="$OPENAI_API_KEY"

nullspace functions status langgraph-service --service fnsvc_123
nullspace functions logs langgraph-service --service fnsvc_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 Function version, service instance, backing machine, 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 machine tool instead. See LangChain for that pattern.