Skip to content

docs updates #2691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
akshaydeo merged 1 commit into from
Apr 13, 2026
Merged

docs updates #2691

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/architecture/framework/model-catalog.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -321,7 +321,7 @@ You can reload the pricing configuration at runtime if you need to change the pr
newConfig := &modelcatalog.Config{
PricingSyncInterval: 12 * time.Hour,
}
err := modelCatalog.ReloadPricing(ctx, newConfig)
err := modelCatalog.UpdateSyncConfig(ctx, newConfig)
```

## Error Handling and Fallbacks
Expand Down
17 changes: 0 additions & 17 deletions docs/changelogs/v1.5.0-prerelease2.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,24 +49,8 @@ description: "v1.5.0-prerelease2 changelog - 2026-04-08"
- **Data Race Fix** — Fix race in data reading from fasthttp request for integrations
- **Model Listing** — Unify /api/models and /api/models/details listing behavior

<Warning>
**v1.5.0 contains multiple breaking changes.** See the [v1.5.0 Migration Guide](/migration-guides/v1.5.0) for full before/after examples and a migration checklist.
</Warning>

## Breaking Changes in This Release

This prerelease introduces 3 additional breaking changes on top of those in prerelease1. See the **[v1.5.0 Migration Guide](/migration-guides/v1.5.0)** for full before/after examples, automatic migration details, and a step-by-step checklist.

| # | Breaking Change | Affected |
|---|---|---|
| [9](/migration-guides/v1.5.0#breaking-change-9-provider-deployments-removed-migrate-to-aliases) | Provider `deployments` removed — migrate Azure, Bedrock, Vertex, and Replicate deployment maps to the unified top-level `aliases` field | `config.json`, REST API, Go SDK |
| [10](/migration-guides/v1.5.0#breaking-change-10-go-sdk-extrafields-model-fields-renamed) | Go SDK: `ExtraFields.ModelRequested` replaced by `OriginalModelRequested` + `ResolvedModelUsed` | Go SDK |
| [11](/migration-guides/v1.5.0#breaking-change-11-go-sdk-streamaccumulatorresult-field-renamed) | Go SDK: `StreamAccumulatorResult.Model` replaced by `RequestedModel` + `ResolvedModel` | Go SDK |

---
</Update>
<Update label="Core" description="1.5.1">
- feat: add model alias support — map model names to provider-specific identifiers per key
- feat: add Fireworks AI as a first-class provider (thanks [@ivanetchart](https://github.com/ivanetchart)!)
- feat: add realtime provider interfaces, schemas, and engine hooks
- feat: add session log storage and realtime request normalization
Expand All @@ -89,7 +73,6 @@ This prerelease introduces 3 additional breaking changes on top of those in prer

</Update>
<Update label="Framework" description="1.3.1">
- feat: add model alias storage and encryption in key config
- feat: add per-user OAuth consent flow with identity selection and MCP authentication
- feat: add access profiles for fine-grained permission control
- feat: add user level OAuth for MCP gateway
Expand Down
94 changes: 94 additions & 0 deletions docs/changelogs/v1.5.0-prerelease3.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
---
title: "v1.5.0-prerelease3"
description: "v1.5.0-prerelease3 changelog - 2026-04-13"
---
<Tabs>
<Tab title="NPX">
```bash
npx -y @maximhq/bifrost --transport-version v1.5.0-prerelease3
```
</Tab>
<Tab title="Docker">
```bash
docker pull maximhq/bifrost:v1.5.0-prerelease3
docker run -p 8080:8080 maximhq/bifrost:v1.5.0-prerelease3
```
</Tab>
</Tabs>

<Update label="Bifrost(HTTP)" description="1.5.0-prerelease3">
## ✨ Features

- **OAuth MCP** - add next-step hints to OAuth MCP client creation response
- **Azure passthrough** - added azure passthrough support
- **272k token tier** - add 272k token tier pricing support in pricing
- **Flex and priority tier support** - added flex and priority tier support in pricing

## 🐞 Fixed

- **Streaming Post-Hook Race** — Fix race condition where fasthttp RequestCtx could be recycled before transport post-hooks complete in streaming goroutines; eagerly captures request/response snapshots before handler returns
- **Async User Values** — Propagate user values through all async inference handlers and job submissions
- **Trace Completer Safety** — Refactor trace completer to accept transport logs as parameter instead of reading from potentially recycled context
- **Async Log Store Exceptions** — Fix exception handling in async log store jobs
- **Model Alias Tracking** — Split ModelRequested into OriginalModelRequested and ResolvedModelUsed for accurate model alias resolution tracking
- **MCP Tool Discovery** — Add discovered tools and tool name mapping columns to MCP clients

</Update>
<Update label="Core" description="1.5.2">
- refactor: split ModelRequested into OriginalModelRequested and ResolvedModelUsed for model alias tracking
- refactor: simplify Azure passthrough by removing redundant config nil checks
- refactor: simplify Mistral error parsing signature
- fix: carry ProviderResponseHeaders through text completion response conversion

</Update>
<Update label="Framework" description="1.3.2">
- feat: add MCP client discovered tools and tool name mapping migration
- fix: exception handling in async log store jobs
- refactor: model catalog Init API to use SetShouldSyncGate method
- refactor: rename DefaultPricingSyncInterval to DefaultSyncInterval

</Update>
<Update label="compat" description="0.1.1">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="governance" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="jsonparser" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="litellmcompat" description="0.1.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="logging" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="maxim" description="1.6.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="mocker" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="otel" description="1.2.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="prompts" description="1.0.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="semanticcache" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
<Update label="telemetry" description="1.5.2">
- chore: upgraded core to v1.5.2 and framework to v1.3.2

</Update>
1 change: 1 addition & 0 deletions docs/docs.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -489,6 +489,7 @@
"item": "Open Source",
"icon": "rocket",
"pages": [
"changelogs/v1.5.0-prerelease3",
"changelogs/v1.5.0-prerelease2",
"changelogs/v1.5.0-prerelease1",
"changelogs/v1.4.22",
Expand Down
106 changes: 28 additions & 78 deletions docs/enterprise/setting-up-okta.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ This guide walks you through configuring Okta as your identity provider for Bifr
- An Okta organization with admin access
- Bifrost Enterprise deployed and accessible
- The redirect URI for your Bifrost instance (e.g., `https://your-bifrost-domain.com/login`)

- Ensure you have created all the [roles in Bifrost](/enterprise/rbac) that you are aiming to map to with Okta.
---
Comment on lines +16 to 17
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Missing blank line before horizontal rule

The new prerequisite bullet is immediately followed by --- with no blank line. Some Markdown parsers may render --- as a heading underline (<h2>) for the preceding list item rather than a <hr>.

Suggested change
- Ensure you have created all the [roles in Bifrost](/enterprise/rbac) that you are aiming to map to with Okta.
---
- Ensure you have created all the [roles in Bifrost](/enterprise/rbac) that you are aiming to map to with Okta.
---


## Step 1: Create an OIDC Application
Expand Down Expand Up @@ -71,39 +71,12 @@ Configure the following settings for your application:

---

## Step 3: Configure Authorization Server (optional)
## Step 3: Create Custom Role Attribute

<Note>
The default authorization server (`/oauth2/default`) is available to all Okta plans and **supports custom claims**, including role claims. The API Access Management paid add-on is only required to create additional custom authorization servers beyond the default.
You can use both roles and/or groups for assigning roles to users. You can learn more about [RBAC](/enterprise/rbac) docs. Roles take precedence over groups in role assignment.
</Note>

Bifrost uses Okta's Authorization Server to issue tokens. You have three options:

1. **Use `/oauth2/default` with role claims (recommended)** — Complete Steps 4-7 to configure custom role claims on the default authorization server. This enables automatic RBAC synchronization.

2. **Use `/oauth2/default` without role claims** — Skip Steps 4-7. The first user to sign in automatically receives the Admin role and can manage RBAC for all subsequent users through the Bifrost dashboard.

3. **Skip Step 3 entirely** — Authorization is not configured through Okta. You'll need an alternative authentication mechanism.

### Configuring the Authorization Server

1. Navigate to **Security** → **API**
2. Click on **Authorization Servers**

<Frame>
<img src="/media/user-provisioning/okta-authorization-server.png" alt="Okta Authorization Servers" />
</Frame>

3. Note the **Issuer URI** for your authorization server (e.g., `https://your-domain.okta.com/oauth2/default`)

<Note>
The Issuer URI is used as the `issuerUrl` in your Bifrost configuration. Make sure to use the full URL including `/oauth2/default` (or your custom authorization server path).
</Note>

---

## Step 4: Create Custom Role Attribute

To map Okta users to Bifrost roles (Admin, Developer, Viewer), you need to create a custom attribute.

1. Navigate to **Directory** → **Profile Editor**
Expand Down Expand Up @@ -133,7 +106,7 @@ To map Okta users to Bifrost roles (Admin, Developer, Viewer), you need to creat

---

## Step 5: Add Role Claim to Tokens
## Step 4: Add Role Claim to Tokens

Configure the authorization server to include the role in the access token.

Expand Down Expand Up @@ -164,11 +137,11 @@ If you named your custom attribute differently, update the Value expression acco

---

## Step 6: Configure Groups for Team and Role Synchronization
## Step 5: Configure Groups

Bifrost can automatically sync Okta groups for two purposes:
- **Team synchronization** — Groups are synced as Bifrost teams
- **Role mapping** — Groups can be mapped to Bifrost roles (Admin, Developer, Viewer) using Group-to-Role Mappings in the Bifrost UI
- **Role mapping** — Groups can be mapped to Bifrost roles (Admin, Developer, Viewer) using Group-to-Role Mappings in the Bifrost UI.

### Create Groups in Okta

Expand All @@ -191,31 +164,6 @@ Use a consistent naming convention for your groups. This makes it easier to conf

### Add Groups Claim to Tokens

You have two options for configuring the groups claim. Choose the one that best fits your Okta plan and requirements.

#### Option A: Using App-Level Groups Claim (All Okta Plans)

This approach configures the groups claim directly in your application's settings and works with all Okta plans, including free tiers.

1. Navigate to your application's **Sign On** tab
2. Scroll down to the **OpenID Connect ID Token** section
3. Click **Edit** to modify the settings
4. Configure the **Groups claim filter**:
- **Groups claim type**: Filter
- **Groups claim filter**: Set a claim name (e.g., `groups`) and filter condition (e.g., "Starts with" `bifrost-staging`)

<Frame>
<img src="/media/user-provisioning/okta-app-group-claim-setup.png" alt="Application Groups claim configuration" />
</Frame>

5. Click **Save**

<Note>
The filter ensures only relevant groups are included in the token. Adjust the filter condition based on your group naming convention.
</Note>

#### Option B: Using Authorization Server Groups Claim

This approach adds the groups claim through your authorization server, providing more flexibility for complex configurations.
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Dangling "This approach" reference

After removing Option A / Option B, the opening sentence "This approach adds the groups claim through your authorization server…" has no referent. Readers arriving at this section for the first time won't know what "this approach" means relative to any alternative.

Suggested change
This approach adds the groups claim through your authorization server, providing more flexibility for complex configurations.
Configure the groups claim through your authorization server, which supports flexible configurations and works across Okta plans.


1. Navigate to **Security** → **API** → **Authorization Servers**
Expand All @@ -235,25 +183,9 @@ Configure the groups claim:

5. Click **Create**

You can also configure an additional groups claim in the application's Sign On settings:

1. Navigate to your application's **Sign On** tab

<Frame>
<img src="/media/user-provisioning/okta-group-configuration.png" alt="Application Sign On configuration" />
</Frame>

2. Under **OpenID Connect ID Token**, configure:
- **Groups claim type**: Expression
- **Groups claim expression**: `Arrays.flatten(Groups.startsWith("OKTA", "bifrost", 100))`

<Note>
Adjust the group filter expression based on your naming convention. The example above includes groups starting with "bifrost".
</Note>

---

## Step 7: Assign Users to the Application
## Step 6: Assign Users to the Application

1. Navigate to your application's **Assignments** tab

Expand All @@ -263,7 +195,9 @@ Adjust the group filter expression based on your naming convention. The example

2. Click **Assign** → **Assign to People** or **Assign to Groups**

3. For each user, set their **bifrostRole**:
### For Assigning Roles

For each user, set their **bifrostRole** (if you are planning to do role-level mapping):

<Frame>
<img src="/media/user-provisioning/okta-assign-custom-role.png" alt="Assign custom role to user" />
Expand All @@ -277,6 +211,22 @@ Role claims are available only when you configure custom claims on your authoriz

---

## Step 7: Create API token for bulk user and team sync

To create an API token, navigate to **Security** → **API** → **Tokens**.

<Frame>
<img src="/media/user-provisioning/okta-tokens-screen.png" alt="Okta API tokens screen" />
</Frame>

1. Click on "Create token"

<Frame>
<img src="/media/user-provisioning/okta-create-token-form.png" alt="Create token dialog in Okta" />
</Frame>

2. Copy token to be used in the next step.

## Step 8: Configure Bifrost

Now configure Bifrost to use Okta as the identity provider.
Expand All @@ -297,9 +247,9 @@ Now configure Bifrost to use Okta as the identity provider.
4. Toggle **Enabled** to activate the provider
5. Click **Save Configuration**

### Group-to-Role Mappings (Optional)
### Group-to-Role Mappings

If you configured groups in Okta (Step 6), you can map Okta group names directly to Bifrost roles. This is an alternative to using custom role claims (Steps 4-5) and works with all Okta plans.
If you configured groups in Okta (Step 5), you can map Okta group names directly to Bifrost roles. This is an alternative to using custom role claims (Steps 3-4) and works with all Okta plans.

1. In the User Provisioning configuration, scroll down to **Group-to-Role Mappings**
2. Click **Add Mapping**
Expand Down
Loading
Loading