JVM-native GraphQL federation platform - feddi

GraphQL Federation Platform

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.

Sign up free<br>Get started

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

The Problem

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.

How it works

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)

Features

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.

Pricing

Start free, scale as you grow

No credit card required to get started.

Free<br>Enterprise

Self-hosted feddi Gateway (open source)✓✓<br>feddi CLI — automate everything✓✓<br>Graphs, variants &...