Fern

Fern is an open-source developer-experience platform for API providers. Point it at an OpenAPI spec (or its own more expressive Fern Definition YAML, plus AsyncAPI and Protobuf support), and its CLI compiles that definition into a versioned Intermediate Representation that every downstream generator consumes. From that single IR, Fern produces idiomatic, type-safe client SDKs for TypeScript, Python, Java, Go, Ruby, PHP, C#, Rust, and Swift, plus server boilerplate and an OpenAPI spec exporter for teams that started from Fern’s own definition format.

Beyond code generation, Fern builds and hosts a full documentation website from the same API definition: an interactive API reference, versioned markdown pages, dark mode, and an AI-powered search assistant trained on a team’s docs, APIs, and SDKs. Docs built with Fern are used in production by companies like ElevenLabs, LaunchDarkly, and Hume — the CLI can scaffold and preview these sites locally before publishing.

The project originated from Y Combinator’s 2023 batch and is maintained by Birch Solutions under the Fern name. It’s structured as a large TypeScript monorepo (pnpm + Turborepo) containing the CLI, the IR compiler, the OpenAPI/AsyncAPI/Protobuf importers, every per-language generator, and a seed/ directory of golden-file SDK fixtures used to regression-test all nine generators on every change. Language generators also ship as Docker images (the fernapi/fern-*-sdk family) so they can run locally or in Fern’s remote generation service.

Fern’s differentiator versus generating SDKs directly from OpenAPI templates is that IR-first design: adding a new spec format doesn’t require touching nine generators, and the IR can evolve (via a dedicated ir-migrations package) without breaking SDKs already generated by older CLI versions. The CLI itself, all generators, and the OpenAPI/Protobuf importers are Apache-2.0 licensed and free to self-run; the hosted docs dashboard and AI search are Fern’s commercial SaaS offering.

What You Get

• A CLI (fern-api on npm) that scaffolds a fern/ workspace from an existing OpenAPI spec with fern init --openapi
• Type-safe SDK generators for TypeScript, Python, Java, Go, Ruby, PHP, C#, Rust, and Swift, each runnable locally via Docker or in Fern’s cloud
• A hosted API documentation site generator with an interactive API reference, markdown pages, versioning, dark mode, and custom domains
• An AI-powered docs search assistant trained on a team’s own API definitions, SDKs, and documentation content
• Importers that convert existing OpenAPI, AsyncAPI, and Postman/Mintlify-authored docs into a Fern workspace
• An OpenAPI spec exporter so teams that adopt the Fern Definition format are never locked into it

Common Use Cases

• API-first startups generating official SDKs in every popular language without maintaining nine separate codegen pipelines
• Platform teams replacing hand-rolled OpenAPI-generator templates with SDKs that get automatic changelogs and semantic versioning
• Developer relations teams standing up a branded, versioned API reference site (like ElevenLabs’ or LaunchDarkly’s docs) straight from their spec
• Companies migrating from a docs tool like Mintlify or a Postman collection into a git-versioned, code-reviewable documentation workflow
• Teams that need webhook, WebSocket (AsyncAPI), or gRPC (Protobuf) definitions represented alongside REST endpoints in one unified spec

Under The Hood

Architecture Fern’s CLI (packages/cli/cli) is a yargs-based command router that wires together dozens of command modules — init, generate, docs, register, upgrade — on top of a layered pipeline: workspace loaders parse a repository’s fern/ directory or raw OpenAPI file into an internal workspace object, an IR generator compiles that workspace into a versioned Intermediate Representation defined in the ir-sdk package, and local or remote workspace runners hand that IR to per-language generator packages, invoked either as sandboxed Docker containers or through a remote generation service. This mirrors a compiler’s frontend/IR/backend split, with a dedicated ir-migrations package preserving backward compatibility as the IR schema evolves across CLI releases — changing the core IR contract is the one thing that would ripple across every generator, so it is the most carefully versioned surface in the codebase.

Tech Stack The monorepo is TypeScript throughout, managed with pnpm workspaces using catalog-based dependency pinning and orchestrated by Turborepo for cached, parallel builds across dozens of packages. Testing runs on Vitest, linting and formatting on Biome (with Stylelint for SCSS and cspell for spelling), and the CLI itself is built on yargs. Per-language code generators are containerized and published as Docker images, invoked through a custom container-runner abstraction, and Devbox/Nix pins the full development toolchain (Node, pnpm, Go, Python, Poetry, JDK, buf) for reproducible contributor environments. The pnpm workspace configuration also enforces supply-chain hardening, requiring new dependency versions to age before they can be installed.

Code Quality The repository has extensive automated test coverage, with test suites embedded in nearly every package and generator plus a dedicated seed/ directory of golden-file SDK snapshots used to regression-test all nine language generators end-to-end on every change. Errors are propagated through structured CLI-context and task-context abstractions rather than raw throws, configuration files are validated against auto-generated JSON Schemas checked into the repo, and CI runs compile, lint, and test jobs with Turborepo remote caching plus a fast path that skips full runs for seed-snapshot-only commits. Biome linting runs with warnings promoted to errors in CI.

What Makes It Unique While several tools generate SDKs from OpenAPI, Fern’s IR-first design decouples spec-format support from language support: OpenAPI, AsyncAPI, Protobuf, and Fern’s own definition format all compile down to one shared representation, so adding a new input format doesn’t require reworking nine separate generators, and the IR can evolve without breaking SDKs already generated by older CLI versions. Fern also generates its hosted documentation site — complete with an AI search assistant trained on a team’s own API surface — from that same source of truth, unifying SDK and docs generation under a single pipeline rather than treating them as separate tools.

Self-Hosting

Licensing Model Apache License 2.0 — the CLI, all nine language generators, the OpenAPI/AsyncAPI/Protobuf importers, and the IR compiler are fully open source and free to self-run with no license keys required.

Self-Hosting Restrictions None found in the codebase. The generators can be run entirely locally via Docker (fern generate --local) without contacting any Fern-operated service, and generated SDKs carry no runtime license checks.

Enterprise Features Fern’s commercial offering is the hosted documentation platform at buildwithfern.com — a dashboard for publishing and versioning the API docs site, custom domains, and the AI-powered docs search assistant. These are operated as Fern’s SaaS product rather than shipped in this repository; the README links to a sign-up flow and a bookable demo for teams wanting the hosted service.

Cloud vs Self-Hosted Code generation (SDKs and server boilerplate) is identical whether run locally via Docker or through Fern’s remote generation service. Documentation hosting, custom domains, and AI search are only available through the hosted dashboard; self-hosters can still generate and preview a docs site locally but would need their own hosting for production deployment.

License Key Required No — no license key or account is required to generate SDKs or docs sites locally with the open-source CLI.