close

The first JVM-native GraphQL federation gateway.

Federation inside your JVM. No foreign runtime, no governance gap, no proprietary directives. Built on the GraphQL federation spec.

Built by Andi Marek, creator of GraphQL Java, the runtime powering Spring GraphQL and Netflix DGS, and team.

Always open source. Self-hosted. No vendor lock-in.

# 1. authenticate
feddi auth login --token fddi_...
✓ Authenticated as you@company.com
# 2. create your graph
feddi graph create $ORG_ID "payments-api"
✓ Created graph: payments-api
feddi variant create $GRAPH_ID production
✓ Created variant: production
# 3. publish your subgraphs
feddi subgraph publish $ID --schema ./orders.graphqls
✓ Schema published. Composition successful.
feddi subgraph publish $ID --schema ./users.graphqls
✓ Schema published. Composition successful.
⬡ supergraph ready — start the gateway

Every federation gateway runs outside your JVM

Policy runs twice

Your custom policy and enforcement logic lives in the JVM. A Rust or Go gateway can't reach it in-process, so you rebuild it outside the JVM or expose it over HTTP, adding latency at every enforcement point.

Operations fracture

Your team owns the JVM stack end to end: deployment, tuning, debugging, on-call. A Rust or Go gateway is a separate discipline with its own runbooks and expertise your platform team now has to carry.

Compliance overhead

Every compliance audit now covers an additional runtime and a separate tech stack your security team must validate independently.

feddi Gateway runs on the JVM. Your subgraphs don't have to.

From subgraphs to unified API

Three steps and you're running federation.

Step 01

Publish your subgraph schemas

Push each subgraph schema to feddi via CLI. feddi validates the schema and stores it. Every push triggers automatic composition.

Need an access token? Sign up free — takes 30 seconds.

feddi subgraph publish $ID --schema ./orders.graphqls
✓ Schema published. Composition successful.
Step 02

Composition runs automatically

On every publish, feddi composes your subgraphs, validates compatibility and blocks breaking changes before they reach production.

feddi subgraph publish $ID --schema ./orders.graphqls
△ Breaking: Query.order field type changed
Field has 4,821 requests in last 30 days
Schema NOT published. Composition unsuccessful.
Step 03

Self-host the gateway

Run the feddi Gateway as a standalone Java process in your existing infrastructure. It polls for schema updates and routes all GraphQL traffic locally. Your data never leaves.

feddi-gateway
✓ Gateway started on :8080
✓ Supergraph loaded (3 subgraphs)

Everything federation needs

Built on the official spec. Designed for production.

Schema registry

One source of truth

Every subgraph schema, composition result, and change history in one place. feddi tracks ownership, validates compatibility across teams, and gives platform leads full visibility across the supergraph.

Spec-compliant

No vendor lock-in

feddi implements the official GraphQL Composite Schemas specification. Standard federation directives, no proprietary extensions.

Analytics & safety

Know before you break

Field-level usage tracking shows you which fields are in active use. Breaking change detection rejects dangerous schema changes or warns you when a field is truly unused.

feddi usage fields $VARIANT_ID
Query.orders12,847 req0 errors
Order.lineItems9,203 req0 errors
Query.user6,441 req2 errors

Input usage

Know before you remove an argument

Before removing an argument, check who's still passing it and when they last did. feddi tracks every argument and input object field your clients actually send.

CLI & agent-first

Automate everything

Manage your entire federation from the terminal. Every action is a CLI command with machine-readable output, built to work with AI coding agents like Claude Code, Cursor, and Copilot.

Self-hosted gateway

Your traffic stays yours

The feddi Gateway runs in your own infrastructure alongside your subgraphs. GraphQL traffic never passes through feddi's servers. The platform only handles metadata.

In-process extensions

Extend the gateway in Java, zero latency

feddi extensions run inside the JVM alongside your feddi Gateway. No network hop, no coprocess overhead.

Persisted documents

Safelist your operations

Pre-register GraphQL operations so clients send a hash instead of a full query string. Smaller payloads, no arbitrary query execution, and a dedicated publish key for your CI pipeline.

feddi pdl publish $PDL_ID --document ./ops.graphql
✓ 12 operations published.
3 already existed, skipped.

Start free, scale as you grow

No credit card required to get started.

Free Enterprise
Self-hosted feddi Gateway (open source)
feddi CLI — automate everything
Graphs, variants & subgraphsUnlimitedUnlimited
Persisted documents
In-process gateway extensions
Breaking change detection
Usage-informed breaking changes
Single sign-on (SSO)
Audit logging
Usage analytics
Operations / month1MUnlimited
Retention30 daysCustom
Field & operation usage
Input field usage
Client & version breakdown
Organization
MembersUp to 10Unlimited
Support
SupportCommunityPriority
SLACustom
Get Started Free Talk to us

Free

 

  • Unlimited graphs, variants & subgraphs
  • Persisted documents
  • In-process gateway extensions
  • Breaking change detection
  • Self-hosted feddi Gateway
  • feddi CLI — automate everything
  • 1M operations / month, 30-day retention
  • Field & operation usage
  • Up to 10 members
  • Community support
Get Started Free

Enterprise

Everything in Free, plus:

  • Unlimited operations & custom retention
  • Usage-informed breaking changes
  • Input field usage
  • Client & version breakdown
  • Unlimited members
  • Single sign-on (SSO)
  • Audit logging
  • Priority support & custom SLA
Talk to us

Get in touch

You'll hear back from the people who built it.