For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
预约演示登录免费开始
  • 使用 SDK
    • SDK 概述
    • SDK 如何工作
    • Quickstart
    • Customer showcase
  • 使用 SDK
    • 项目结构
    • 添加自定义代码
    • Migrating to Replay
    • 功能特性
  • 参考
      • 自托管 SDK
      • Versioning
  • 资源
    • generators.yml
Checking status...
SOC2Soc 2 Type II
© 2026 Fern • Birch Solutions, Inc., a Postman company

Documentation

SDKsDocsAsk FernCLI Reference

API Definitions

OpenAPIAsyncAPIOpenRPCgRPC

Resources

BlogSupportPricing

Company

Brand KitPrivacy PolicyTerms of Service
LogoLogo
预约演示登录免费开始
在本页
  • --version AUTO (recommended)
  • Deterministic versioning with fern ir + fern diff
  • Wiring fern ir + fern diff into CI
SDK 设计

Self-hosted SDK versioning

||以 Markdown 格式查看|
此页面是否有帮助?
在仪表板中编辑
上一个

自托管 SDK

下一个

generators.yml 配置模式

Enterprise feature

This feature is available only for the Enterprise plan. To get started, reach out to support@buildwithfern.com.

When self-hosting, your pipeline picks the version number for each SDK release. Unlike cloud generation, self-hosted setups need to compute the next version themselves.

The CLI exposes two workflows for this. Both can be wired into the same generation pipeline:

  • --version AUTO is the recommended approach. Fern classifies the change against the full SDK output — so changes driven by generators.yml settings, a generator version bump, or a CLI version bump are reflected in the version it picks — and writes the changelog entry, PR description, and conventional-commit message for you. This is also the path that continues to receive improvements.
  • fern ir + fern diff is the deterministic alternative. It compares the intermediate representation (IR) of your API spec and returns only the computed bump and next version. Because the diff is over the spec alone, it doesn’t account for SDK-implementation changes that come from generators.yml configuration, generator version, or CLI version — if any of those move, you’ll need to bump the version yourself. The rest of the release artifacts (changelog, PR description, commit message) are also yours to write. Use this flow when you need explicit control over how the version number is derived, or when you can’t depend on an external LLM provider.

--version AUTO (recommended)

Pass --version AUTO to fern generate and Fern analyzes the diff between the previous and current SDK output, classifies the change as MAJOR, MINOR, or PATCH, and applies the next semantic version to the generated package. The same analysis also produces:

  • A changelog entry describing what changed
  • A PR description summarizing the release
  • A conventional commit message

--version AUTO requires:

  • A FERN_TOKEN for organization verification (same as all self-hosted generation).
  • A GitHub output configured in generators.yml, since the pipeline pushes the version bump and changelog back to the SDK repo.
1

Configure the AI provider

Set the provider and model in generators.yml:

generators.yml
1ai:
2 provider: openai # openai | anthropic | bedrock
3 model: gpt-4o # any model name the provider accepts
2

Set provider credentials

Export the matching API key so the Fern CLI can call the provider:

  • OPENAI_API_KEY for OpenAI
  • ANTHROPIC_API_KEY for Anthropic
  • Standard AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION) for AWS Bedrock

The diff is sent to the provider’s API using your credentials — Fern’s infrastructure is not involved in the analysis.

3

Run generation with --version AUTO

$FERN_TOKEN=<token> fern generate --local --version AUTO

Deterministic versioning with fern ir + fern diff

If you’d rather derive the version number yourself, use the fern ir and fern diff commands to compute the bump from your API definition. This flow has no LLM dependency: fern diff walks the intermediate representation (IR) of both specs and returns a deterministic result.

The workflow has three steps:

1

Generate the previous IR

Check out the spec as it was at the last SDK generation and write its IR to disk:

$fern ir old-ir.json

Pass --api <name> if your project defines multiple APIs.

2

Generate the current IR

Check out the spec at HEAD and write its IR to disk:

$fern ir new-ir.json
3

Diff the two IRs

Run fern diff with --from-version set to the SDK’s current version. When --from-version is provided, the command prints a JSON object containing the computed bump and the next version:

$fern diff \
> --from old-ir.json \
> --to new-ir.json \
> --from-version 1.4.2
1{
2 "bump": "minor",
3 "nextVersion": "1.5.0",
4 "errors": []
5}

bump is one of major, minor, patch, or no_change. Pass nextVersion to fern generate to release that exact version:

CLI v1
CLI v2
$fern generate --local --version 1.5.0

fern diff exits with a non-zero status when the computed bump is major. This makes it easy to gate breaking changes on a manual review step in CI.

Wiring fern ir + fern diff into CI

The non-obvious part is reproducing the IR for the previous spec. Each generated SDK records the config repo commit it was generated from in .fern/metadata.json:

.fern/metadata.json
1{
2 "cliVersion": "0.74.0",
3 "generatorName": "fernapi/fern-python-sdk",
4 "generatorVersion": "4.0.0",
5 "originGitCommit": "a1b2c3d4e5f6...",
6 "requestedVersion": "1.4.2",
7 "sdkVersion": "1.4.2"
8}

originGitCommit is the SHA in the config repo that produced the SDK at its current version. Check that commit out, run fern ir, then switch back to HEAD and run fern ir again to produce both inputs to fern diff.

Example: GitHub Actions workflow

The following snippet runs in the config repo on every push to main and computes the next version for a Python SDK whose originGitCommit and sdkVersion are read from the SDK repo:

.github/workflows/release-sdk.yml
1name: Release SDK
2
3on:
4 push:
5 branches: [main]
6
7jobs:
8 release:
9 runs-on: ubuntu-latest
10 env:
11 FERN_TOKEN: ${{ secrets.FERN_TOKEN }}
12 SDK_REPO: your-org/python-sdk
13 steps:
14 - name: Check out config repo
15 uses: actions/checkout@v4
16 with:
17 fetch-depth: 0
18
19 - name: Set up Fern CLI
20 uses: fern-api/setup-fern-cli@v1
21
22 - name: Read previous SDK metadata
23 id: meta
24 run: |
25 curl -fsSL \
26 -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
27 -H "Accept: application/vnd.github.raw" \
28 "https://api.github.com/repos/${SDK_REPO}/contents/.fern/metadata.json" \
29 > metadata.json
30 echo "old_sha=$(jq -r .originGitCommit metadata.json)" >> "$GITHUB_OUTPUT"
31 echo "from_version=$(jq -r .sdkVersion metadata.json)" >> "$GITHUB_OUTPUT"
32
33 - name: Generate previous IR
34 run: |
35 git checkout ${{ steps.meta.outputs.old_sha }}
36 fern ir old-ir.json --api <your-api-name>
37
38 - name: Generate current IR
39 run: |
40 git checkout ${{ github.sha }}
41 fern ir new-ir.json --api <your-api-name>
42
43 - name: Compute next version
44 id: diff
45 run: |
46 result=$(fern diff \
47 --from old-ir.json \
48 --to new-ir.json \
49 --from-version ${{ steps.meta.outputs.from_version }}) || true
50 bump=$(echo "$result" | jq -r .bump)
51 if [ "$bump" = "major" ]; then
52 echo "Computed a major version bump — manual review required before releasing."
53 exit 1
54 fi
55 echo "next_version=$(echo "$result" | jq -r .nextVersion)" >> "$GITHUB_OUTPUT"
56
57 - name: Generate SDK
58 run: fern generate --local --group python-sdk --version ${{ steps.diff.outputs.next_version }}

fetch-depth: 0 on the checkout step is required so the runner has the history needed to check out originGitCommit. Replace the metadata-fetch step with whatever mechanism gives your pipeline access to the SDK repo’s .fern/metadata.json (a checkout of the SDK repo, a release artifact, an internal API, and so on).