Aegra is live · free · last verified 24 Oct 2026 · viability monitor
Aegra
Self-hosted Agent Protocol server that runs LangGraph agents on your own Postgres with the same LangGraph SDK.
Aegra solves the specific complaint that pushes LangGraph teams toward migrations: checkpoints trapped in someone else's cloud, per-run pricing, and auth you can't bend. The URL-swap story is real and the Postgres-as-plain-tables design means no proprietary export. What you take on is ops — a Redis-backed worker fleet, Postgres, and upgrade cycles — so pick it if you already run that stack, and pass if you don't.
Verdict generatedVerified 6d ago · liveness 68/100 · cite: rightaichoice.com/tools/aegra
- LangGraph SDK developers who want the same client code pointed at their own server
- Teams under data residency or compliance rules that need checkpoints to stay in-region
- AI engineers who want thread authorization written as Python decorators, not configured in a UI
- Platform teams already running Docker, Postgres, and Redis in production
- Teams that want managed agent hosting and zero infrastructure work
- Developers not already building on the LangGraph SDK
- Non-technical users wanting a no-code agent builder or hosted chat UI
We scan live Reddit threads, YouTube comments, X posts, G2 reviews and other communities — and hand you an honest verdict in under a minute.
- Honest verdict, not marketing
- Real pros & cons from real users
- Attributed quotes with receipts
3 free scans · no card needed
Skip Aegra if you don't want to run Docker, PostgreSQL, and a Redis queue yourself, or if you aren't already building on the LangGraph SDK — there's no agent builder here, just a protocol server your existing client code talks to.
You run PostgreSQL and Redis yourself, so database hosting, backups, and storage bills land on your cloud account rather than a vendor invoice.
The homepage states Aegra is Apache 2.0 with free unlimited deployment, bring-your-own Postgres, custom auth, and no license key, and explicitly says there is no enterprise tier hiding features. Its own comparison puts self-hosting on LangSmith Deployments at Enterprise with a license key. For a team already paying for Postgres and Redis, that makes Aegra an infrastructure-cost line rather than a per-seat platform fee.
In short
Aegra — Self-hosted Agent Protocol server that runs LangGraph agents on your own Postgres with the same LangGraph SDK. Best for LangGraph SDK developers who want the same client code pointed at their own server, Teams under data residency or compliance rules that need checkpoints to stay in-region, AI engineers who want thread authorization written as Python decorators, not configured in a UI. Free to use.
What is Aegra?
Aegra — Self-hosted Agent Protocol server that runs LangGraph agents on your own Postgres with the same LangGraph SDK. Best for LangGraph SDK developers who want the same client code pointed at their own server, Teams under data residency or compliance rules that need checkpoints to stay in-region, AI engineers who want thread authorization written as Python decorators, not configured in a UI. Free to use.
Aegra is an open-source Agent Protocol server for running LangGraph agents on infrastructure you own. If your code already calls the LangGraph SDK, the migration is a URL swap: get_client(url=MANAGED_DEPLOYMENT_URL) becomes get_client(url="https://agents.yourcompany.com") and the client side stays as it is. The target audience is LangGraph developers and platform teams who already run Docker, Postgres, and Redis in production and want to stop paying usage-metered agent hosting. Persistence is the pitch. Threads, runs, and checkpoints land in your Postgres as plain tables — queryable with SQL, backup-able on your own schedule, and stayable in your region. Migrations run on server start. The server speaks the endpoints the LangGraph SDK already calls, including POST /threads, POST /threads/{id}/runs/stream, GET /threads/{id}/state, POST /assistants/search, PUT /store/items, and POST /runs/crons, and it lists compatibility with the Python and JS LangGraph SDKs. Streaming runs emit token, value, and event output over SSE with resume after a disconnect. Background execution sits on a Redis queue with leases, heartbeats, and crash recovery, so you scale out by adding worker instances instead of filing a support ticket. Authorization is ordinary Python — one decorator per resource, such as @auth.on.threads.create, lets you wire JWT, OAuth, or Firebase and scope each thread to its owner. Tracing goes to any OTLP backend as a server setting; the page names Langfuse, Phoenix, or your own collector, with every run as a trace and every node as a span. It also lists Agent Chat UI as a drop-in, LangGraph Studio connecting to any deployment, and CopilotKit over AG-UI. Aegra's own comparison table positions it against LangSmith Deployments on self-hosting under Apache 2.0 and bring-your-own Postgres. This is a backend for people already inside the LangGraph ecosystem — not a no-code builder and not a managed cloud.
Key features
- Self-hosted Agent Protocol server for LangGraph agents
- Drop-in URL swap for existing LangGraph SDK clients
- LangGraph SDK compatibility for Python and JS
- Agent Protocol endpoints: threads, runs, state, assistants, store, crons
- PostgreSQL persistence for threads, runs, and checkpoints as plain tables
- Migrations applied automatically on server start
- Custom auth in Python via decorators such as @auth.on.threads.create
- Auth providers: JWT, OAuth, Firebase
- Per-thread ownership scoping to the authenticated user
- SSE streaming of token, value, and event output
- Resume streaming runs after a client disconnect
- Redis worker queue with leases, heartbeats, and crash recovery
- OTLP tracing to Langfuse, Phoenix, or a custom collector
- Every run a trace, every node a span, set as a server setting
- AG-UI compatible chat frontend via CopilotKit
Behind the verdict
We'd reach for Aegra the moment a LangGraph project hits one of three walls: data residency rules that forbid checkpoints leaving your region, a billing curve that punishes predictable high traffic, or an authorization model the managed platform can't express. All three land in the same place — you want the agent runtime on your own Postgres, and you want your existing SDK client code to keep working. The migration is genuinely small if you're already on the LangGraph SDK. One line changes. Threads and runs keep the same shape, SSE streaming still delivers tokens and values, and resume-after-disconnect still holds. That's the part that makes this different from rewriting on a new framework. Where it bites is the ops surface. You are running a Redis queue with leases and heartbeats, a Postgres you now own the backups for, and a server that needs upgrading. One community report has it running alongside a Next.js app on a 4 GB / 3 CPU VPS, and another team runs it on Kubernetes at inventory-mapping scale — but both of those are teams who know their way around containers. The auth decorator pattern deserves credit. Scoping threads to their owner in Python beats fighting a UI, and it fits JWT, OAuth, or Firebase without a special plan tier. Observability through OTLP as a server setting is the right default too; pointing it at Langfuse or Phoenix is config, not instrumentation code. Closest alternative is LangSmith Deployments. You pick Aegra when you need self-hosting, your own database, and Python auth without an enterprise conversation; you stay managed when nobody on the team wants to page someone about a worker restart. Watch out for two things. First, this is Apache 2.0 at $0, which means no support contract to escalate — the Discord is your lifeline. Second, if
Limitations
- Self-hosted only: Aegra runs on your infrastructure, so you own the Docker deployment, PostgreSQL database, and Redis queue, including backups and scaling.
- It is a backend, not a builder — it assumes you already have LangGraph agent code and the LangGraph SDK, and it ships no end-user interface of its own (the homepage points to Agent Chat UI, LangGraph Studio, and CopilotKit for that).
- Auth is code, not configuration: you write Python handlers for JWT, OAuth, or Firebase rather than toggling settings.
- There is no managed control plane, so upgrades, migrations on start, and worker health are your responsibility.
as of 2026-10-05
Researching Aegra? Get your full AI stack in 60 seconds.
Free, no signup — tell us your goal and get tools matched to your budget & existing stack.
Is Aegra still active?
Aegra is live · free · last verified 24 Oct 2026 · viability monitor.
Viability score
How well maintained and how widely used is Aegra? Built from what the vendor actually publishes (docs, changelog, tutorials, integrations, pricing), whether the site is live, and how much real users discuss it. How we calculate this
Last calculated: October 2026
How we score →What do users say about Aegra?
What people actually say about Aegra — is it worth it?
Our community sentiment research written Jul 29, 2026 is more than 90 days old, so it is being re-reviewed against current data and is not shown.
How we verified this
Every listed fact about Aegra — pricing, features, links, status — is re-read from the vendor's own pages by our verification pipeline and each change is logged with a date; the last pass ran on 24 Oct 2026. Analysis is drafted with AI models and checked against our editorial standards before publishing; see how we verify.
Verification history
We have re-verified Aegra 11 times since . Each pass re-reads the vendor's own pages and re-checks every listed field against that evidence; passes where nothing had changed are marked as such.
- — changed who it suits, description, summary, pricing tiers, our verdict, who should skip it, features
- — changed features, who should skip it, who it suits, summary, integrations, description, our verdict, pricing tiers
- — changed limitations, models, platforms, pricing page
- — changed pricing tiers, pricing fit, use cases, limitations, who should skip it, setup time, hidden costs, switching in, integrations, switching out, features, summary, our verdict, who it suits, description
- — changed limitations
- — changed SSL certificate
Showing the 6 most recent of 11 verification passes.
Free to cite with attribution — this page re-verifies continuously.
How much does Aegra cost in 2026?
Aegra: Free to use. Pricing last verified 24 Oct 2026.
Plans compared
Every published Aegra tier, its price as the vendor publishes it, who it fits, and what it adds over the tier below. The 12-month cost projection follows.
| Plan | Price | Billing | Who it's for |
|---|---|---|---|
| Community | Free | — | LangGraph SDK developers and small teams who can run Docker, PostgreSQL, and Redis and want agents on their own infrastructure without a license key.Adds: Starting tier: unlimited self-hosted deployment under Apache 2.0, bring-your-own Postgres, Python JWT/OAuth/Firebase auth, and OTLP tracing. |
12-month cost
Project the real annual outlay, including the implied monthly cost when only an annual tier is published.
Vendor list price only. Add-on usage, seat overages, and contract minimums are surfaced under Hidden costs & gotchas.
Where the pricing makes sense
The company stage and team size where Aegra's pricing actually pencils out — and where peers do it cheaper.
The homepage states Aegra is Apache 2.0 with free unlimited deployment, bring-your-own Postgres, custom auth, and no license key, and explicitly says there is no enterprise tier hiding features. Its own comparison puts self-hosting on LangSmith Deployments at Enterprise with a license key. For a team already paying for Postgres and Redis, that makes Aegra an infrastructure-cost line rather than a per-seat platform fee.
Has Aegra's pricing changed?
No plan price for Aegra has moved since we began logging in Aug 2026; the pricing page is re-read on every verification pass.
Who should pick Aegra?
Pick Aegra if you are LangGraph SDK developers who want the same client code pointed at their own server, Teams under data residency or compliance rules that need checkpoints to stay in-region, AI engineers who want thread authorization written as Python decorators, not configured in a UI, Platform teams already running Docker, Postgres, and Redis in production.
Look elsewhere if you are Teams that want managed agent hosting and zero infrastructure work, Developers not already building on the LangGraph SDK, Non-technical users wanting a no-code agent builder or hosted chat UI, Anyone unwilling to operate and upgrade a Redis-backed worker fleet.
Skip it if Skip Aegra if you don't want to run Docker, PostgreSQL, and a Redis queue yourself, or if you aren't already building on the LangGraph SDK — there's no agent builder here, just a protocol server your existing client code talks to.
GeneratedReal-world workflow fit
Concrete scenarios for the personas Aegra actually fits — and what changes day-one when you adopt it.
Change get_client(url=MANAGED_DEPLOYMENT_URL) to get_client(url="https://agents.yourcompany.com"), bring up the Aegra server and Postgres, and let migrations run on start.
Outcome: Existing LangGraph SDK client code keeps working unchanged, with threads and checkpoints now in a Postgres the team controls.
Write Python auth handlers with the @auth.on decorator, wiring JWT, OAuth, or Firebase and scoping each thread to its owner.
Outcome: Per-thread access control is enforced at the server layer instead of being bolted onto each agent.
Deploy Aegra with Docker alongside a Next.js app on a 4 GB / 3 CPU VPS, stream responses over SSE with resume after disconnect, and point tracing at an OTLP backend.
Outcome: A production agent endpoint with no usage-metered hosting bill, as reported by a community user running the same setup.
Use cases
- Point your existing LangGraph SDK client at your own Aegra URL to move off a managed deployment without rewriting agent code.
- Run customer support agents in production on your own Postgres so threads and checkpoints stay in your region.
- Write custom JWT, OAuth, or Firebase auth handlers in Python so every thread is scoped to its owner.
- Scale a queue-backed agent workload horizontally by adding worker instances behind a Redis queue.
- Send every run as a trace and every node as a span to Langfuse, Phoenix, or your own OTLP collector.
- Serve a streaming chat front end through Agent Chat UI or an AG-UI client such as CopilotKit.
- Run agent infrastructure on a small VPS with Postgres when you don't want per-node cloud costs.
Setup time & first value
How long it actually takes to get something useful out of Aegra — broken out by persona, not the marketing-page minute.
For a LangGraph SDK developer, the client-side change is one line, so first value is minutes once the server is up. Standing up the server itself means Docker, PostgreSQL, and a Redis queue, plus migrations that run on start — realistically an afternoon for a developer comfortable with Compose, longer if auth handlers or OTLP tracing need configuring. Teams without Docker or Postgres experience
Switching to or from Aegra
How to bring data in from common predecessors and how to get it back out — written for the switcher, not the buyer.
- →From LangSmith Deployments: keep your LangGraph SDK client code and change the client URL to your Aegra server; Aegra implements the Agent Protocol endpoints the SDK already speaks.
- →From a self-managed LangGraph app: move thread, run, and checkpoint state into your own Postgres, which stores them as plain tables with migrations on start.
- →From callback-based tracing: switch tracing from per-app callbacks to an OTLP backend set once as a server setting (Langfuse, Phoenix, or your own collector).
- →From a shared-auth setup: replace it with Python auth handlers via the @auth.on decorator using JWT, OAuth, or Firebase.
- ↗To a managed LangGraph platform: point the same LangGraph SDK client back at a hosted deployment URL.
- ↗To self-hosted LangGraph without a platform server: export your threads and checkpoints from Postgres, which stores them as plain tables.
- ↗To a different AG-UI-compatible front end: your agent server keeps serving the Agent Protocol, so the client layer can change independently.
Integrations
Resources & guides
Tutorials & Learning
YouTube returned 6 videos for “Aegra”, and we withheld 6: 6 could not be judged, because “Aegra” is a single word that other videos use for other things. We are showing none, because we could not prove any of them are about Aegra.
Official links
What are the best Aegra alternatives?
The closest alternatives to Aegra we list are Yao, Agno and xpander.ai. Ranked by direct product-type match, not category overlap.
| Alternative | Pricing | Starts at | Last verified |
|---|---|---|---|
| Yao | Freemium | Pricing not published | — |
| Agno | Freemium | Pricing not published | — |
| xpander.ai | Freemium | Pricing not published | — |
Alternatives to Aegra
View all
Yao
Yao Agents is a self-hosted AI agent runtime that runs autonomous agents across every computer you own.
Agno
Open-source Python SDK plus AgentOS runtime for serving agents as a REST API and MCP server you host yourself.
xpander.ai
Enterprise agent runtime that runs Claude Code, Codex, and OpenCode agents inside your own cloud with governance and budgets
Tools that pair well with Aegra
Common stack mates teams adopt alongside Aegra, with the specific reason each pairing earns its keep.
Yao
Yao Agents is a self-hosted AI agent runtime that runs autonomous agents across every computer you own.
Agno
Open-source Python SDK plus AgentOS runtime for serving agents as a REST API and MCP server you host yourself.
xpander.ai
Enterprise agent runtime that runs Claude Code, Codex, and OpenCode agents inside your own cloud with governance and budgets
Aegra vs its closest rival
Aegra's closest head-to-head is with Spider Cloud — Spider Cloud and Aegra are not direct competitors: Spider Cloud is a web scraping API for feeding real-time data to AI agents, while Aegra is a self-hosted backend for deploying LangGraph agents. Choose Spider Cloud if you need to extract structured web data at scale for RAG pipelines. Choose Aegra if you're already using LangGraph and want to avoid per-node fees by self-hosting. Both are developer-friendly, open-source-influenced tools with strong community support. Verdict generated
Head-to-head comparisons
Aegra vs Spider Cloud
Spider Cloud and Aegra are not direct competitors: Spider Cloud is a web scraping API for feeding real-time data to AI agents, while Aegra is a self-hosted backend for deploying LangGraph agents. Choose Spider Cloud if you need to extract structured web data at scale for RAG pipelines. Choose Aegra if you're already using LangGraph and want to avoid per-node fees by self-hosting. Both are developer-friendly, open-source-influenced tools with strong community support.
GeneratedAegra vs Temporal Ai
Choose Temporal AI if you need a battle-tested durable execution platform for complex, long-running workflows with automatic recovery, and you're okay with usage-based billing at scale. Choose Aegra if you're already using LangGraph and want to self-host without per-node fees, gaining full data control—and you're comfortable managing your own infrastructure. They serve different ecosystems: Temporal is general-purpose workflow orchestration; Aegra is a LangGraph-specific deployment backend.
GeneratedAegra vs Presto Voice
Presto Voice and Aegra serve entirely different markets: Presto automates drive-thru ordering for QSR chains with a proven upselling engine, while Aegra lets LangGraph developers self-host agent backends without per-node fees. Choose Presto if your business runs multiple drive-thru locations and wants measurable revenue lift; choose Aegra if you need a cost-effective, customizable backend for LangGraph agents with full data control.
GeneratedFrequently asked questions
Topics
Used Aegra? Help shape our editorial sentiment research.