Tauri Updater Proxy

A high-performance, multi-provider auto-updater and release notes proxy server for Tauri v2 applications. It allows you to securely distribute updates and release notes from private or public repositories across all major Git hosting platforms.

Supported platforms include GitHub (Cloud & Enterprise Server), GitLab (Cloud & Self-Managed), Gitea / Forgejo / Codeberg, GitVerse, GitFlic, Bitbucket Cloud, Azure DevOps, and OneDev.

It shields your access tokens from end-users, streams installer downloads, handles multi-channel releases (stable and prerelease), and serves markdown/MDX release notes.

Features

Multi-Provider Support: First-class support for GitHub, GitLab, Gitea, Forgejo, Codeberg, GitVerse, GitFlic, Bitbucket, Azure DevOps, and OneDev (including self-hosted/enterprise instances).
Token Security: Hides credentials from client apps; end-users never see or need API tokens.
Dynamic Updates: Natively compatible with @tauri-apps/plugin-updater v2 format.
Multi-Channel Releases: Segregates stable and prerelease (beta/alpha) channels.
Flexible Channel Selection: Supports channel selection via HTTP header or query parameter, with well-defined priority.
Binary Streaming: Efficiently proxies binary downloads (.exe, .zip, .sig, .dmg, etc.) directly from release assets without memory bloat.
Static Manifest Support: Serves latest.json, latest.stable.json, and latest.prerelease.json manifests from release assets (sorted strictly by SemVer 2.0) or directly from the repository with automated fallbacks.
Rich Release Notes System: Serves dedicated version release notes written in Markdown or MDX (release-notes/<version>.mdx), with full YAML frontmatter parsing (title, date, tags), multi-language BCP 47 localization support, and automatic fallbacks to provider release notes when needed.
Multi-Language Support (i18n): Serves localized release notes via ?lang= query parameter or X-App-Language header with BCP 47 tags (e.g. 1.3.1.pt-BR.mdx, 1.3.1.pt.mdx) and configurable fallback chains (FALLBACK_LANGUAGE).
Full Customization: Configurable manifest resolution strategy (MANIFEST_SOURCE), target repository branch (REPO_BRANCH), manifests folder (MANIFESTS_DIR), release notes folder (RELEASE_NOTES_DIR), and fallback language (FALLBACK_LANGUAGE).

API Endpoints Reference

1. Check for Updates

GET /update/:target/:version

Primary endpoint for the Tauri updater client.

Route Parameters:
- :target — Target platform identifier (e.g. windows-x86_64, windows-aarch64, darwin-aarch64, linux-x86_64).
- :version — Currently installed client version (e.g. 1.3.1, 1.4.0-beta.1).
Channel Selection: via ?channel= query parameter or X-Update-Channel header.
Responses:
- 204 No Content: The client is already running the latest version.
- 200 OK: A new version is available. Returns Tauri-compliant update metadata with direct download links pointing to /download?asset_id=....

2. Download Release Asset

GET /download?asset_id=:id

Securely proxies the release binary asset download from the Git provider.

Query Parameters:
- asset_id — Provider release asset identifier.
Response:
- Streams or redirects to the file with Content-Type: application/octet-stream and proper Content-Disposition.

3. Static Manifests

GET /latest.json
GET /latest.:channel.json

Serves static release manifests (latest.json, latest.stable.json, latest.prerelease.json) according to the MANIFEST_SOURCE strategy:

auto (default): Searches for the manifest asset among published releases sorted descending by SemVer 2.0 (picking the highest version regardless of publication date, preventing hotfixes on older branches from downgrading clients). If not found in releases, automatically falls back to the repository under <MANIFESTS_DIR>.
releases: Strictly searches among release assets.
repo: Strictly searches repository files under <MANIFESTS_DIR> (defaults to the repository root).
Channel Selection: via filename (e.g. /latest.prerelease.json), ?channel= query parameter, or X-Update-Channel header.
Fallback: If a channel-specific file is not present in the release or repository, automatically falls back to latest.json.

4. Version Release Notes (Rich Markdown / MDX)

GET /release-notes/:version
GET /changelogs/:version    (alias for backward compatibility)

Fetches the release notes for a specific version, with full multi-language (i18n) localization support.

Route Parameters:
- :version — Version string (e.g. 1.3.1, v1.3.1, 1.4.0-beta.1).
Language / Locale Selection:
- ?lang= query parameter (highest priority, e.g. ?lang=pt-BR, ?lang=ru, ?lang=en).
- X-App-Language HTTP header (e.g. X-App-Language: pt-BR).
- If neither is provided, falls back to the configured FALLBACK_LANGUAGE (or en).
File Structure & Layouts (RELEASE_NOTES_DIR_STRUCTURE): Release notes are placed in <RELEASE_NOTES_DIR> (defaults to release-notes/) using BCP 47 language tags across two supported directory structures:
- Nested subfolders (nested): <RELEASE_NOTES_DIR>/<locale>/<version>.mdx or .md
  - e.g. release-notes/pt-BR/1.3.1.mdx, release-notes/pt/1.3.1.mdx, release-notes/en/1.3.1.mdx
- Flat files (flat): <RELEASE_NOTES_DIR>/<version>.<locale>.mdx or .md and base <version>.mdx
  - e.g. release-notes/1.3.1.pt-BR.mdx, release-notes/1.3.1.pt.mdx, release-notes/1.3.1.mdx
Resolution & Fallback Strategy:
1. Configurable via RELEASE_NOTES_DIR_STRUCTURE:
  - auto (default): Searches nested subfolders first across the locale fallback chain. If no localized file is found in nested folders, falls back to flat files across the same fallback chain, and finally the base <version>.mdx file.
  - nested: Searches strictly inside nested subfolders (<locale>/<version>.mdx).
  - flat: Searches strictly among flat files (<version>.<locale>.mdx and <version>.mdx).
2. Locale fallback chain example (when client requests pt-BR and FALLBACK_LANGUAGE=en-US):
  - pt-BR (client regional locale)
  - pt (client base language)
  - en-US (configured fallback locale)
  - en (configured/default base fallback)
3. If no matching file is found in the repository, falls back to the body of the corresponding provider release/tag (release.body).
4. Optimized for performance: executes exactly 1 network request to list repository files and matches candidates in-memory.

Response Example:

{
  "version": "1.3.1",
  "locale": "pt-BR",
  "releasedAt": "2026-09-21T18:23:25Z",
  "tags": ["feature", "fix"],
  "notes": "Full markdown content with frontmatter stripped"
}

5. Release Notes Index (List Versions)

GET /release-notes
GET /changelogs    (alias for backward compatibility)

Returns an array of all available versions that have release notes files in <RELEASE_NOTES_DIR>.

Channel Selection: Pass ?channel=stable or header X-Update-Channel: stable to filter out pre-release versions.

Response Example:

{
  "versions": ["1.4.0-beta.2", "1.4.0-beta.1", "1.3.1", "1.3.0"]
}

(Sorted descending according to SemVer 2.0).

Update Channels & Precedence

Channel names are fully arbitrary strings (e.g. stable, prerelease, alpha, beta, nightly, canary, preview, dev) and are not restricted to a fixed set:

stable (reserved keyword, default): Exclusively serves official, non-prerelease releases. Any release marked as draft or pre-release is filtered out.
Any other channel name (e.g. prerelease, alpha, beta, nightly, canary, etc.):
- In /update/:target/:version: Activates pre-release eligibility, serving pre-release builds if newer than the client version. If a newer final stable release is published, pre-release clients also receive it.
- In /latest.json: Dynamically looks for latest.<channel>.json in the repository (e.g. channel=nightly looks for latest.nightly.json, channel=alpha looks for latest.alpha.json), automatically falling back to latest.json if the channel file does not exist.

Priority / Precedence Rules

When determining the release channel, the server applies the following priority order:

$$\text{Query Parameter}; (\texttt{?channel=}) \quad \mathbf{>} \quad \text{HTTP Header}; (\texttt{X-Update-Channel}) \quad \mathbf{>} \quad \text{Default}; (\texttt{stable})$$

Query Parameter (?channel=...): Takes highest precedence. Useful for manual testing, browser links, and direct overrides.
HTTP Header (X-Update-Channel: ...): Used by automated client libraries (like Tauri v2 check({ headers })).
Default (stable): Used when neither the query parameter nor the header is provided.

Usage in Tauri v2

Pass the headers option to check() in @tauri-apps/plugin-updater:

import { check } from '@tauri-apps/plugin-updater';

// Check for stable updates (default)
const update = await check({
  headers: {
    'X-Update-Channel': 'stable',
  },
});

// Check for pre-release / beta updates
const betaUpdate = await check({
  headers: {
    'X-Update-Channel': 'prerelease',
  },
});

Environment Variables

Configure these variables in your deployment environment (e.g. Vercel Project Settings):

Variable	Required	Default	Description
`GIT_PROVIDER`	No	`github`	Git provider: `github`, `gitlab`, `gitea`, `gitverse`, `gitflic`, `bitbucket`, `azure_devops`, or `onedev`.
`GIT_TOKEN`	Yes	—	Personal Access Token with repository read access.
`REPO_OWNER`	Yes	—	Repository owner / group / organization. For Azure DevOps: `org` or `org/project`.
`REPO_NAME`	Yes	—	Repository / project name.
`GIT_API_URL`	No	—	Custom API Base URL for self-hosted instances (e.g. `https://gitlab.mycompany.com/api/v4`, `https://github.corp.com/api/v3`, `https://codeberg.org/api/v1`). Auto-detected if empty.
`REPO_BRANCH`	No	`main`	Target repository branch for fetching manifests (`latest*.json`) and release notes.
`MANIFEST_SOURCE`	No	`auto`	Manifest resolution strategy: `auto` (release assets first, fallback to repo), `releases` (only release assets), or `repo` (only repository files).
`MANIFESTS_DIR`	No	`""` (root)	Target directory in repository where release manifests (`latest*.json`) are located (used when served from repository).
`RELEASE_NOTES_DIR`	No	`release-notes`	Target directory in repository where release notes (`.md` / `.mdx`) are located.
`RELEASE_NOTES_DIR_STRUCTURE`	No	`auto`	Directory layout for release notes: `auto` (nested first, fallback to flat), `nested`, or `flat`.
`FALLBACK_LANGUAGE`	No	`en`	Fallback language / locale when requested translation is unavailable (e.g. `en`, `en-US`, `ru`).

Provider Setup Examples

1. GitHub (Default)

GIT_PROVIDER=github
GIT_TOKEN=ghp_yourPersonalAccessTokenHere
REPO_OWNER=my-org
REPO_NAME=my-app

For GitHub Enterprise Server: set GIT_API_URL=https://github.mycompany.com/api/v3.

2. GitLab (Cloud or Self-Managed)

GIT_PROVIDER=gitlab
GIT_TOKEN=glpat-yourPersonalAccessTokenHere
REPO_OWNER=my-group
REPO_NAME=my-app

For GitLab Self-Managed: set GIT_API_URL=https://gitlab.mycompany.com/api/v4.

3. Gitea / Forgejo / Codeberg

GIT_PROVIDER=gitea
GIT_TOKEN=your_gitea_token
REPO_OWNER=my-org
REPO_NAME=my-app
GIT_API_URL=https://codeberg.org/api/v1  # or https://gitea.mycompany.com/api/v1

4. GitVerse (Сбер / СберТех)

GIT_PROVIDER=gitverse
GIT_TOKEN=your_gitverse_token
REPO_OWNER=my-org
REPO_NAME=my-app

Pre-configured with https://gitverse.ru/api/v1.

5. GitFlic (ГК «Астра» / Ресолют)

GIT_PROVIDER=gitflic
GIT_TOKEN=your_gitflic_token
REPO_OWNER=my-alias
REPO_NAME=my-project

Pre-configured with https://api.gitflic.ru (set GIT_API_URL for self-hosted GitFlic Enterprise).

6. Bitbucket Cloud

GIT_PROVIDER=bitbucket
GIT_TOKEN=your_app_password_or_token  # For Basic auth: username:app_password
REPO_OWNER=my-workspace
REPO_NAME=my-repo

7. Azure DevOps

GIT_PROVIDER=azure_devops
GIT_TOKEN=your_azure_personal_access_token
REPO_OWNER=my-organization/my-project
REPO_NAME=my-repo

8. OneDev

GIT_PROVIDER=onedev
GIT_TOKEN=your_onedev_access_token
REPO_OWNER=my-group
REPO_NAME=my-project
GIT_API_URL=https://code.onedev.io/~api  # or https://onedev.mycompany.com/~api

Deployment to Vercel

Create a Git repository (e.g. tauri-proxy-updater) and push this project.
Log in to Vercel and click Add New -> Project.
Select your repository, leave Framework Preset as Other, and click Deploy.
In the Vercel Dashboard, go to Settings -> Environment Variables and add your provider configuration (e.g. GIT_PROVIDER, GIT_TOKEN, REPO_OWNER, REPO_NAME).
Redeploy the latest deployment to apply the environment variables.

Configuring Tauri Application

In your Tauri project's tauri.conf.json, specify your proxy endpoint:

"plugins": {
  "updater": {
    "pubkey": "<your-tauri-pubkey>",
    "endpoints": [
      "https://your-proxy.vercel.app/update/{{target}}-{{arch}}/{{current_version}}"
    ]
  }
}

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
.husky		.husky
.vscode		.vscode
api		api
lib		lib
.env.example		.env.example
.gitignore		.gitignore
README.md		README.md
eslint.config.ts		eslint.config.ts
lint-staged.config.js		lint-staged.config.js
package-lock.json		package-lock.json
package.json		package.json
prettier.config.js		prettier.config.js
tsconfig.json		tsconfig.json
vercel.json		vercel.json

Navigation Menu

Repository navigation

About

Repository files navigation

Tauri Updater Proxy

Features

API Endpoints Reference

1. Check for Updates

2. Download Release Asset

3. Static Manifests

4. Version Release Notes (Rich Markdown / MDX)

5. Release Notes Index (List Versions)

Update Channels & Precedence

Priority / Precedence Rules

Usage in Tauri v2

Environment Variables

Provider Setup Examples

1. GitHub (Default)

2. GitLab (Cloud or Self-Managed)

3. Gitea / Forgejo / Codeberg

4. GitVerse (Сбер / СберТех)

5. GitFlic (ГК «Астра» / Ресолют)

6. Bitbucket Cloud

7. Azure DevOps

8. OneDev

Deployment to Vercel

Configuring Tauri Application

About

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

Tauri Updater Proxy

Features

API Endpoints Reference

1. Check for Updates

2. Download Release Asset

3. Static Manifests

4. Version Release Notes (Rich Markdown / MDX)

5. Release Notes Index (List Versions)

Update Channels & Precedence

Priority / Precedence Rules

Usage in Tauri v2

Environment Variables

Provider Setup Examples

1. GitHub (Default)

2. GitLab (Cloud or Self-Managed)

3. Gitea / Forgejo / Codeberg

4. GitVerse (Сбер / СберТех)

5. GitFlic (ГК «Астра» / Ресолют)

6. Bitbucket Cloud

7. Azure DevOps

8. OneDev

Deployment to Vercel

Configuring Tauri Application

About

Topics

Resources

Stars

Watchers

Forks

Contributors

Languages