Fern: OpenAPI in, SDKs and docs out

The problem Fern solves: hand-written SDKs drift from the spec

Every team with a public API eventually faces the same maintenance loop. The OpenAPI file changes, and the TypeScript, Python, Java and Go clients each need a matching edit. Miss one and users file bugs against a client that no longer matches the server. Fern's answer is to treat the API definition as the only source and generate the clients from it. The README describes the output as "production-ready SDKs and beautiful documentation in minutes," and the generator table lists targets for TypeScript, Python, Java, Go, Ruby, PHP, C#, Swift and Rust.

The audience is narrower than the tagline suggests. This is a tool for API platform teams, the people who own the spec and the developer-facing surface around it. A solo developer wrapping a private endpoint in a thin client will spend more time learning the fern/ directory layout than writing the client by hand. The value appears when the number of target languages, or the number of documentation pages, crosses the point where manual upkeep becomes a recurring chore.

How the generator pipeline works: spec in, artifacts out

The mechanism is a directory convention plus a generator registry. Running fern init with an OpenAPI path produces a fern/ folder containing fern.config.json, generators.yml and an openapi/ subdirectory holding the spec. The README shows exactly this layout:

fern/
├─ fern.config.json
├─ generators.yml # generators you're using
└─ openapi/
  └─ openapi.json # your openapi document

generators.yml is the part that decides what comes out. Generators are separate processes identified by IDs such as fernapi/fern-typescript-sdk or fernapi/fern-python-sdk, and the README states they take your API definition as input and output artifacts, including server boilerplate. You add one with fern add <generator id>. Running fern generate then invokes the configured generators and, per the README, leaves the TypeScript SDK in /generated/sdks/typescript.

The repository itself is a pnpm workspace. The root package.json sets engines to node >=20.0.0 and pnpm ^11.0.0, and declares npm as "please-use-pnpm", so anyone building the tool from source rather than installing the published CLI is expected to use pnpm. Scripts such as compile, test and test:ete run through turbo across packages. That is a build detail, not something a user of the CLI touches, but it explains why the repo carries schemas like fern-yml.schema.json and generators-yml.schema.json at the top level: the config files are validated against published schemas.

Installing Fern and generating a first SDK

The CLI is distributed on npm as fern-api and, according to the README, requires Node 18 or later. Install it globally:

npm install -g fern-api

Initialize a project against a local spec, or against a hosted one. The README gives both forms, including a plantstore example URL:

fern init --openapi ./path/to/openapi.yml
# or
fern init --openapi https://link.buildwithfern.com/plantstore-openapi

That creates the fern/ directory described above. To pick which SDK to emit, add a generator by its ID, then run the generator:

fern add fernapi/fern-typescript-sdk
fern generate

When the command finishes, the README says the SDK appears under /generated/sdks/typescript. If that directory is empty or missing, the first thing to check is whether generators.yml actually lists a generator, since fern generate only runs what is configured there.

The documentation side is a separate starter. The README points to the fern-api/docs-starter repository rather than describing an inline command, and notes that extra pages are written in markdown and versioned with git. Search, SEO, dark mode and the component set are described as provided out of the box, with colors, fonts, logo and domain name customizable.

Where Fern gets in the way

The README is explicit that the platform is available through the CLI and a dashboard, and several links point at buildwithfern.com for sign-up and demos. That means the hosted documentation path is not purely local. A team that wants the docs site without any account relationship with the vendor is reading the wrong section of the README; the SDK generation path is the part that runs from the CLI alone.

The second constraint is the directory convention. Fern owns fern/ and the shape of generators.yml. If your repository already has an established layout for API artifacts, or if your build system expects to find the spec somewhere else, you either move the file or add a copy. The README does not document a way to point the generator at an arbitrary spec location outside that structure, so treat the convention as fixed.

The third is version drift. Generator versions are published independently, and the README links a separate changelog per language. Nothing in the README describes a lockfile or a pinning mechanism for generator IDs, so a build that regenerates against the latest generator can produce a diff you did not ask for. The repository does carry a fern-versions-yml.schema.json, which suggests version configuration exists, but the README does not explain it. That gap is worth resolving before you wire generation into CI.

Fern compared with OpenAPI Generator and Speakeasy

OpenAPI Generator is the obvious alternative, and the difference is architectural rather than cosmetic. OpenAPI Generator runs as a local Java tool with a large set of built-in templates, and you invoke it per language, per run, with flags for the generator name and output directory. Fern instead keeps a persistent fern/ directory, a generators.yml registry and a hosted platform behind the docs and AI search features. If you want a generator you fully control, can fork and run offline with no account, OpenAPI Generator's model fits better. If you want the docs site, the search assistant and the reference pages generated from the same definition, Fern bundles those, and OpenAPI Generator does not attempt to.

Speakeasy occupies similar ground to Fern: spec in, SDKs and docs out, with a managed pipeline. The README does not cover Speakeasy, so the honest comparison is limited to positioning. What can be said from the README is that Fern's generator list spans TypeScript, Python, Java, Go, Ruby, PHP, C#, Swift and Rust, and that it accepts OpenAPI, AsyncAPI, Protobuf and OpenRPC rather than REST specs alone. Teams with gRPC or WebSocket surfaces should weigh that breadth; teams with a single REST API and a strong preference for a self-contained CLI have less reason to switch.

Licence, releases and what upgrades cost

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That covers the code in this repository. It does not automatically cover the hosted platform: the README routes sign-up, demos and the dashboard through buildwithfern.com, and the terms of a hosted service are a separate question from the repository licence. Read those terms before assuming the Apache-2.0 grant extends to the hosted docs and search features.

On release cadence, the published CLI versions are 5.23.1, 5.23.2 and 5.23.3, dated 2026-05-11 and 2026-05-12. The last push to the default branch was 2026-09-23. The repository is not archived. Upgrading the CLI is a global npm install, so the cost is low; the cost that matters is regenerating SDKs, because a new generator version can change emitted code. The README's per-language changelog links are the place to check before bumping, and the absence of documented generator pinning is the gap to close first if you run generation in CI.

Editorial conclusion

Adopt Fern if you maintain a public API definition and want generated SDKs in several languages plus a versioned docs site from the same source. Skip it if you only need a one-off client for a private endpoint, since the setup cost of a fern/ directory and generators.yml will not pay off. Before committing, verify the generator versions you intend to pin, and check whether the hosted docs features you want are available on the free tier or require a dashboard account.

Frequently asked questions

Official sources

1. fern-api/fern on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases