Eden is Open Source: A Production-Ready Gateway for Data and AI Workloads

Today we are open-sourcing Eden.

For the last 24 months, our team has been building the gateway layer we wanted to exist for modern data and AI infrastructure: fast enough to sit on production hot paths, aware enough to understand the traffic moving through it, and flexible enough to connect databases, model providers, agents, applications, and infrastructure APIs through one consistent control plane.

That work is now available under the Apache License, Version 2.0.

You can find the repository here:

• GitHub: github.com/eden-dev-inc/eden

This release is an important moment for us, but it is also a practical one. The way teams use infrastructure is changing quickly. A few database connections become dozens of services. A few AI API calls become multiple models, agents, applications, users, cost centers, and policy questions. What starts as "just call the provider" turns into a much harder operating problem:

• Who is using which model, database, or API?
• How much is it costing?
• What data is being sent out?
• Which requests should be allowed, redacted, blocked, routed, mirrored, or audited?
• How do you keep the control plane simple without slowing down the data plane?

Eden exists because we think those questions should be answered at the gateway layer.

Why We Built Eden

Infrastructure teams are being asked to move faster while taking on more responsibility. They are adopting AI, modernizing databases, connecting internal APIs, and trying to make old systems and new systems work together without breaking production.

The easy answer is to push all of that complexity into applications. Add a little more logging here. Add another provider wrapper there. Put rate limits in one service, redaction in another, migration logic somewhere else, and usage accounting in a dashboard that only sees part of the picture.

That approach works for a while. Then the system gets bigger.

Suddenly the organization has model usage it cannot explain, database traffic it cannot safely migrate, APIs that are difficult to govern, and agents that need access to real systems without being handed unlimited trust. The problem is not that teams lack tools. The problem is that the controls are scattered across too many places.

We built Eden around a different idea: put a high-performance, protocol-aware gateway between applications and the systems they depend on, then make that gateway observable, governable, and programmable from one control plane.

In the codebase and product surfaces, that gateway/runtime layer is called Eve.

What Is Open Source Today

The open-source Eden repository includes the Rust gateway and service runtime for connecting to databases, model providers, and infrastructure APIs through a consistent control plane.

The repository includes:

• eden-service, the main service crate for API handlers, auth, and runtime wiring
• eden_gateway, the gateway entry point and protocol gateway implementations
• endpoint schemas and runtime crates for databases, AI providers, cloud services, and APIs
• shared auth, telemetry, analytics, and control-plane primitives
• documentation for deployment, feature flags, metrics, benchmarks, and security

Redis is the production-ready gateway protocol in this release. Other gateway and endpoint surfaces, including Postgres, Mongo, LLM, and agent gateway support, are included for development, evaluation, API review, and community contribution as they continue moving toward production readiness.

That distinction matters. We are open-sourcing a broad platform, but we also want the release to be honest about where each surface is today.

Built for Hot Paths

A gateway is only useful if teams can afford to put it in the path.

That requirement shaped Eden from the beginning. The data plane is written in Rust because we care about predictable latency, memory safety, and high-throughput behavior under real load. The goal was not to build a dashboard that watches traffic from the side. The goal was to build a gateway that can sit inline and still do meaningful work: parse protocols, route requests, emit telemetry, enforce policy, mirror traffic, support migrations, and attribute usage without becoming the bottleneck.

In our Redis benchmark set, Eve matched a controlled 400k requests per second workload with lower tail latency and lower CPU cost per completed request than Envoy's Redis proxy. In the same benchmark brief, the AI gateway path reached 12k requests per second for buffered 64 KiB OpenAI-compatible responses with zero errors.

Benchmarks are never a universal hardware guarantee, but they are useful evidence for the kind of system we are building. Eden is designed for teams that want governance and observability without giving up performance.

Why AI Makes This More Urgent

AI adoption changes the shape of infrastructure work.

Most teams start with a few model calls. Then usage spreads. Product features call one model. Internal tools call another. Agents start taking actions. Different teams want different providers. Finance wants to understand cost. Security wants to know what data is leaving the organization. Engineering wants fallback, routing, latency visibility, and a way to debug failures without reading every application log.

That is the moment an AI gateway becomes necessary.

Eden's AI gateway is designed to sit between applications and model providers, giving teams a central place to manage AI usage as it scales. The gateway architecture includes:

• request identity and API key management
• model routing and route-decision telemetry
• token, cost, cache, route, and agent usage accounting
• per-key, per-org, per-user, and per-agent attribution paths
• rate-limit and budget policy foundations
• prompt and response inspection
• PII audit, redaction, and blocking controls
• OpenAI-compatible model and chat surfaces

The principle is simple: AI traffic should be observable and governable from day one. A company should not have to wait until usage is expensive, fragmented, or risky before it gets basic control over what is happening.

One Gateway for Databases, APIs, and Models

We do not think the future of infrastructure is split cleanly into "AI tools" and "data tools."

AI systems need access to databases, SaaS platforms, internal APIs, logs, metrics, files, and operational systems. Database migrations need traffic visibility, policy, mirroring, validation, and rollback. API workloads need authentication, auditability, and consistent governance. The same underlying requirement keeps appearing: a control point that understands requests without forcing every application team to rebuild the same machinery.

That is why Eden is broader than a single AI proxy or a single database proxy.

Eden is a gateway for:

• production Redis traffic today
• database gateway development across Postgres, Mongo, and other protocols
• OpenAI-compatible AI workloads
• agent and tool traffic
• internal API and infrastructure endpoints
• analytics, telemetry, and governance workflows

The long-term direction is one control plane for the systems your applications and agents already depend on.

What You Can Do With Eden

Depending on the runtime shape you choose, Eden gives teams a foundation for:

• observing request traffic across gateway paths
• tracking usage, latency, tokens, and estimated cost
• auditing activity by organization, API key, user, agent, or consumer
• applying policy before traffic reaches the upstream system
• redacting or blocking sensitive information before it leaves the gateway
• routing requests across providers, models, endpoints, or migration targets
• mirroring and validating traffic during infrastructure changes
• exporting metrics, traces, logs, and analytics for operational visibility

The immediate production path is the Redis gateway. The broader open-source release gives the community access to the architecture, primitives, and development surfaces we are using to extend Eden across AI, database, and API workloads.

Why Open Source

We are open-sourcing Eden because the infrastructure problem it solves is not unique to us.

Every company building with AI is going to need better visibility into model usage. Every team scaling agents is going to need stronger controls around identity, cost, safety, and data access. Every organization modernizing its data stack is going to need safer ways to observe, route, migrate, and govern traffic without rewriting every application.

Those should not be luxuries reserved for teams with enough time to build a custom gateway internally.

By releasing Eden under Apache 2.0, we want teams to be able to run it, inspect it, modify it, contribute to it, and build on top of it. We also want the project to improve in the open. Gateway infrastructure gets better when it sees more workloads, more protocols, more edge cases, and more honest feedback from people running real systems.

If you are building AI-powered products, modernizing databases, managing internal APIs, or thinking seriously about how agents should interact with production infrastructure, we would love for you to try Eden and tell us what you find.

Get Started

The repository is available today:

• GitHub: github.com/eden-dev-inc/eden
• Documentation: docs
• Benchmarks: benchmark summary
• License: Apache License 2.0

If you want the focused production path, start with the Redis gateway build. If you want to evaluate the broader platform, explore the full service runtime, AI gateway architecture, endpoint surfaces, and contribution paths in the repository.

Eden has always been built around a simple belief: the systems that sit between applications and infrastructure should be fast, transparent, and trustworthy.

Now that work is open source.

If you are interested in learning more, Devon will be speaking at RustConf about the novel technology we built to make Eden possible.