Aegra: A Self-Hosted LangGraph Agent Backend That Speaks the Same SDK
Open source alternative to LangGraph Platform (now LangSmith Deployments) - Self-hosted AI agent backend with FastAPI and PostgreSQL. Zero vendor lock-in, full control over your agent infrastructure.
At a glance
- What is it?
- Aegra reimplements the LangSmith Deployments surface in FastAPI and PostgreSQL so existing LangGraph SDK clients keep working against your own infrastructure. The trade is that you now operate the queue, the database and the auth layer yourself.
- Who is it for?
- Adopt Aegra if you already have LangGraph graphs, want the LangGraph SDK to keep working unchanged, and are willing to run Redis and PostgreSQL yourself. Do not adopt it if you have no operational capacity for those two services or if you depend on managed scaling and support contracts.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap Aegra Fills Between a Local Graph and a Hosted Deployment
LangGraph itself is a library. You can run a graph in a script today. The difficulty starts when that graph needs to be reachable over HTTP by a chat UI, survive a process restart mid-run, resume after a human approval step, and keep a thread of conversation in durable storage. LangSmith Deployments solves that, but the README's own comparison table states that self-hosting is an enterprise-only feature requiring a license key, and that bringing your own database is likewise enterprise-tier. Aegra's pitch is narrow and specific: keep the LangGraph SDK on the client side, replace the server side with something you run.
The README calls it a drop-in replacement and shows the client code to prove the point. It imports get_client from langgraph_sdk, points it at http://localhost:2026, creates an assistant from a graph_id, creates a thread, and streams a run. Nothing in that snippet is Aegra-specific. That is the whole argument. If your application is already written against the LangGraph SDK, the migration is a URL change plus a server you now own.
The intended user is a team that has LangGraph graphs working and has hit one of three walls: the hosted tier's data residency does not fit a compliance requirement, the pricing model does not fit the run volume, or the deployment needs custom authentication that the free tier does not expose. Aegra addresses all three, but it addresses them by moving the operational burden onto you.
Worker Architecture, Redis Leases and How a Run Actually Executes
The README describes a worker architecture rather than a simple request-response server. Runs are placed on a Redis job queue, and the documentation states a limit of 30 concurrent runs per instance. Crash recovery uses leases, which means a worker that dies mid-run does not leave the job orphaned; the lease expires and another worker can claim it. Multiple instances scale horizontally, and the streaming guide mentions cross-instance pub/sub, which is what makes horizontal scaling coherent for a streaming API. Without that, a client connected to instance A would never see events emitted by a run executing on instance B.
Persistence is PostgreSQL. The README says checkpoints go through LangGraph's own checkpoint mechanism, so the graph state format is not something Aegra invented. Scheduled cron jobs are claimed with SKIP LOCKED, a PostgreSQL locking clause, which is the standard way to make a job table safe when several workers poll it at once. The README states cron expressions can be either standard 5-field or seconds-level 6-field, with IANA timezone support.
Streaming has two generations in this codebase, and the distinction matters. The legacy path is run-scoped. The newer path is Agent Protocol v2, described as thread-scoped SSE with content-block events, per-subgraph lifecycle, and native human-in-the-loop resume. The README says it is enabled by default and that it is what the latest LangGraph SDKs and useStream() target. If you are pinning an older SDK, that default is worth checking against your client version rather than assuming compatibility.
A semantic store backed by pgvector is listed for vector embeddings, and custom routes let you add your own FastAPI endpoints alongside the generated ones. Observability fans out through OpenTelemetry, and the README explicitly contrasts this with LangSmith-only tracing by naming Langfuse and Phoenix as possible OTLP backends.
Starting a Project With aegra init, aegra dev and the .env File
The documented path uses the CLI. The README warns to install aegra-cli directly rather than the aegra meta-package, stating that the wrapper does not support version pinning. That warning is worth taking literally, since a deployment you cannot pin is a deployment you cannot reproduce.
pip install aegra-cli, then aegra init. The README says init is interactive and prompts for location, template and name, or you can pass a path such as aegra init ./my-agent, in which case it still prompts for the template. After that the printed next steps are to copy .env.example to .env, add an OPENAI_API_KEY, run uv sync, and run uv run aegra dev. The dev command starts PostgreSQL and the development server together with hot reload.
The alternative is building from source: clone the repository, copy .env.example to .env, add the API key, and run docker compose up. The README points at http://localhost:2026/docs for the API explorer, which is FastAPI's generated documentation. For a production process, the CLI exposes aegra serve with no reload, plus aegra up and aegra down for Docker services. aegra version prints version information.
Configuration lives in aegra.json according to the documentation index, and the README links a configuration reference for the format and options. Authentication is configurable across JWT, OAuth, Firebase, or none, and the README describes the custom option as Python handlers. The material does not reproduce the aegra.json schema, so the exact keys for auth mode, checkpoint connection or worker concurrency are not something I can state here. Read the configuration reference before writing that file.
What You Take On: Redis, PostgreSQL and a Version You Must Pin
The honest limitation is in the pitch itself. Zero vendor lock-in means zero vendor support. The README's comparison table lists self-hosted as always available under Apache 2.0, but the same table shows the hosted alternative bundling a managed database and infrastructure. Choosing Aegra means you now own Redis capacity, PostgreSQL backups, connection pooling, and the failure mode where a worker dies holding a lease.
The 30 concurrent runs per instance figure is a documented constraint, not a suggestion. If your workload is bursty, you size instances for the peak or you accept queue latency. Horizontal scaling is described, but it depends on the cross-instance pub/sub path working, which is one more moving part than a single-process server.
There is a second, subtler risk: version alignment. Aegra tracks the LangGraph SDK surface, and the README notes that Agent Protocol v2 streaming is what the latest SDKs target while the legacy run-scoped stream still exists. A project on an older LangGraph SDK may find the default streaming mode is not the one its client expects. The README does not state a compatibility matrix in the material provided, so treat SDK version as something to verify rather than assume.
Finally, the release cadence is fast. v0.10.2, v0.10.3 and v0.10.4 all landed within roughly a week. Rapid patch releases on a 0.x line usually mean the API surface is still settling. That is not a defect, but it does mean upgrade testing belongs in your process rather than being an afterthought.
Aegra Against LangGraph Platform and Against Rolling Your Own FastAPI
The obvious alternative is LangSmith Deployments itself, and the difference is not feature parity but control. The README's table frames it as deploy-anywhere and bring-your-own-Postgres versus managed cloud with self-hosting gated behind an enterprise license. If your constraint is a procurement process or a data residency rule, that gating is the deciding factor and feature comparison is secondary.
The less obvious alternative is writing the FastAPI layer yourself. Aegra is, structurally, a FastAPI application with PostgreSQL persistence and a Redis-backed worker pool. A competent team could build a subset of that. What they would have to rebuild is the part that is tedious rather than clever: Agent Protocol compliance so Agent Chat UI, LangGraph Studio and CopilotKit work without custom glue; the SSE event format including reconnection with event replay; the checkpoint integration; the SKIP LOCKED cron claim; and the lease-based crash recovery. Those are the pieces where a homegrown server quietly diverges from what the LangGraph SDK expects.
A third option is staying local. The README notes that local development is available on the free hosted tier. If your agents never need to be reachable by a browser client, never need cron, and never need to survive a restart mid-run, a library plus a small script is genuinely simpler than any of this. Aegra's own feature list is a good checklist for deciding whether you have outgrown that stage.
Licence, Upgrade Cost and Who Should Walk Away
Aegra is Apache-2.0, which permits commercial use, modification and redistribution with the usual attribution and notice requirements. The README also links a Patreon sponsorship page and a Discord server, which is a funding model rather than a licence term. I am not a lawyer and this is not legal advice: if you are embedding Aegra in a product you distribute, read the LICENSE file and your own counsel's guidance rather than a review.
Maintenance cost is the real line item. You are running PostgreSQL and Redis in production, which means backup strategy, upgrade windows and monitoring for both. The README's observability story helps here: fan-out tracing via OpenTelemetry means you can send traces to Langfuse, Phoenix or another OTLP backend rather than being tied to one vendor's tracing. That is a genuine operational advantage over a LangSmith-only pipeline, and it is the kind of thing that matters more at 3am than in a feature table.
Upgrade cost is tied to the release cadence. With patches landing days apart on a 0.x line, pinning aegra-cli to a known version and reading release notes before bumping is the practical approach. The README's own warning against the unpinnable meta-package points in the same direction.
Walk away if you have no appetite for operating a queue and a database, if you need a support contract with someone accountable for uptime, or if your agents are still single-user scripts. Stay if you have LangGraph graphs, a compliance or cost reason to leave the hosted tier, and engineers who already run Postgres.
Editorial conclusion
Adopt Aegra if you already have LangGraph graphs, want the LangGraph SDK to keep working unchanged, and are willing to run Redis and PostgreSQL yourself. Do not adopt it if you have no operational capacity for those two services or if you depend on managed scaling and support contracts. Before committing, verify that your LangGraph version matches the SDK generation Aegra targets, decide whether you want the legacy run-scoped stream or Agent Protocol v2 thread-scoped streaming, and read the aegra.json reference to confirm your auth mode and checkpoint setup.
Community notes