Forem: Thomas Cosialls

Expo app : RedirectTo field with Supabase Auth always set to localhost

Thomas Cosialls — Mon, 30 Mar 2026 04:44:48 +0000

You are building an Expo Mobile app with Supabase as a backend?

You have correctly set the redirect url to exp:///auth/callback** in the URL Configuration of Supabase Auth and want to try your flow on Expo Go?

If you keep seeing localhost as the redirectTo address in the reset password link set by email, here is the fix:

npx expo start --tunnel

Ship Your Tauri v2 App Like a Pro: GitHub Actions and Release Automation (Part 2/2)

Thomas Cosialls — Fri, 20 Feb 2026 05:22:38 +0000

In Part 1, we set up code signing for macOS (Developer ID + notarization) and Windows (Azure Key Vault). We configured tauri.conf.json, created entitlements, set up relic, and generated updater signing keys.

Now we wire it all together. In this part, we'll build:

A GitHub Actions workflow that builds, signs, and publishes your app for macOS and Windows
A release automation script that bumps versions, generates changelogs, and triggers the pipeline with a single command
The full end-to-end flow from "I want to release v1.0.0" to ".dmg and .exe on GitHub Releases"

GitHub Actions Workflow
- Trigger: Tag-Based Releases
- Build Matrix
- Full Workflow File
- Step-by-Step Breakdown
Repository Settings
- Workflow Permissions
- Adding Secrets
Release Automation Script
- What It Does
- The Script
- npm Script Entry Point
The Full Release Flow
Verifying Your Release
- macOS Verification
- Windows Verification
Troubleshooting
Conclusion

GitHub Actions Workflow

Trigger: Tag-Based Releases

The cleanest approach is triggering builds when you push a version tag. No manual workflow dispatching, no branch-based heuristics -- push a v* tag and the pipeline runs.

on:
  push:
    tags:
      - "v*"

This means v0.1.0, v1.0.0-beta.1, or any tag starting with v will trigger the workflow.

Build Matrix

We need three build targets:

Platform	Target	Output
`macos-latest`	`aarch64-apple-darwin`	`.dmg` for Apple Silicon Macs
`macos-latest`	`x86_64-apple-darwin`	`.dmg` for Intel Macs
`windows-latest`	`x86_64-pc-windows-msvc`	`.exe` NSIS installer

Why not a universal macOS binary? Universal binaries (universal-apple-darwin) combine both architectures into one .dmg, but they double the file size. Separate builds keep downloads smaller, and GitHub Releases can host both.

We use fail-fast: false so one platform failing doesn't cancel the others. If the macOS build fails, you still get the Windows artifact (and vice versa).

Full Workflow File

Create .github/workflows/release.yml:

name: Release

on:
  push:
    tags:
      - "v*"

concurrency:
  group: release-${{ github.ref }}
  cancel-in-progress: true

jobs:
  release:
    permissions:
      contents: write
    strategy:
      fail-fast: false
      matrix:
        include:
          - platform: macos-latest
            args: "--target aarch64-apple-darwin"
            rust_target: aarch64-apple-darwin
          - platform: macos-latest
            args: "--target x86_64-apple-darwin"
            rust_target: x86_64-apple-darwin
          - platform: windows-latest
            args: "--target x86_64-pc-windows-msvc"
            rust_target: x86_64-pc-windows-msvc

    runs-on: ${{ matrix.platform }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
          cache: "npm"

      - name: Install Rust toolchain
        uses: dtolnay/rust-toolchain@stable
        with:
          targets: ${{ matrix.rust_target }}

      - name: Rust cache
        uses: swatinem/rust-cache@v2
        with:
          workspaces: src-tauri

      - name: Install frontend dependencies
        run: npm ci

      - name: Import Apple signing certificate
        if: runner.os == 'macOS'
        env:
          APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
          APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
        run: |
          CERT_PATH=$RUNNER_TEMP/certificate.p12
          KEYCHAIN_PATH=$RUNNER_TEMP/build.keychain-db
          KEYCHAIN_PASSWORD=$(openssl rand -base64 24)

          echo "$APPLE_CERTIFICATE" | base64 --decode > "$CERT_PATH"

          security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
          security default-keychain -s "$KEYCHAIN_PATH"
          security set-keychain-settings -lut 21600 "$KEYCHAIN_PATH"
          security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
          security import "$CERT_PATH" -P "$APPLE_CERTIFICATE_PASSWORD" -A -t cert -f pkcs12 -k "$KEYCHAIN_PATH"
          security set-key-partition-list -S apple-tool:,apple: -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
          security list-keychains -d user -s "$KEYCHAIN_PATH"

          echo "Available signing identities:"
          security find-identity -v -p codesigning "$KEYCHAIN_PATH"

      - name: Build and release
        uses: tauri-apps/tauri-action@v0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # macOS signing + notarization
          APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
          APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
          APPLE_SIGNING_IDENTITY: ${{ secrets.APPLE_SIGNING_IDENTITY }}
          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_PASSWORD: ${{ secrets.APPLE_PASSWORD }}
          # Tauri updater signing
          TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
          TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
          # Windows signing (Azure Key Vault via relic)
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
        with:
          tagName: v__VERSION__
          releaseName: "YourApp v__VERSION__"
          releaseBody: "See [CHANGELOG](https://github.com/YOUR_USERNAME/YOUR_REPO/blob/main/CHANGELOG.md) for details."
          releaseDraft: true
          prerelease: false
          args: ${{ matrix.args }}

Step-by-Step Breakdown

Let's walk through what each step does and why it's there.

Concurrency

concurrency:
  group: release-${{ github.ref }}
  cancel-in-progress: true

If you push a tag, realize there's a typo, delete it, and push a corrected one -- the in-progress build is cancelled. This prevents wasting runner minutes.

Permissions

permissions:
  contents: write

Required for tauri-action to create a GitHub Release and upload artifacts. Without this, you'll get a "Resource not accessible by integration" error.

Checkout

- name: Checkout repository
  uses: actions/checkout@v4

Standard checkout. Nothing special here.

Node.js + npm

- name: Install Node.js
  uses: actions/setup-node@v4
  with:
    node-version: "lts/*"
    cache: "npm"

Uses the latest LTS version and caches node_modules based on package-lock.json. The frontend build runs via beforeBuildCommand in your Tauri config.

Rust Toolchain

- name: Install Rust toolchain
  uses: dtolnay/rust-toolchain@stable
  with:
    targets: ${{ matrix.rust_target }}

Installs the stable Rust toolchain with the specific cross-compilation target. For macOS runners, this might be aarch64-apple-darwin (ARM) or x86_64-apple-darwin (Intel).

Rust Cache

- name: Rust cache
  uses: swatinem/rust-cache@v2
  with:
    workspaces: src-tauri

Caches the target/ directory between runs. Without this, Rust compilation takes 5-15 minutes per build. With caching, subsequent builds are much faster.

Frontend Dependencies

- name: Install frontend dependencies
  run: npm ci

npm ci (not npm install) does a clean install from the lockfile. This ensures reproducible builds.

Apple Certificate Import (macOS only)

- name: Import Apple signing certificate
  if: runner.os == 'macOS'
  env:
    APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
    APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
  run: |
    CERT_PATH=$RUNNER_TEMP/certificate.p12
    KEYCHAIN_PATH=$RUNNER_TEMP/build.keychain-db
    KEYCHAIN_PASSWORD=$(openssl rand -base64 24)

    echo "$APPLE_CERTIFICATE" | base64 --decode > "$CERT_PATH"

    security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
    security default-keychain -s "$KEYCHAIN_PATH"
    security set-keychain-settings -lut 21600 "$KEYCHAIN_PATH"
    security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
    security import "$CERT_PATH" -P "$APPLE_CERTIFICATE_PASSWORD" -A -t cert -f pkcs12 -k "$KEYCHAIN_PATH"
    security set-key-partition-list -S apple-tool:,apple: -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN_PATH"
    security list-keychains -d user -s "$KEYCHAIN_PATH"

    echo "Available signing identities:"
    security find-identity -v -p codesigning "$KEYCHAIN_PATH"

This is the most involved step. Here's what each line does:

Decode the certificate -- the base64-encoded .p12 from your secret is written to a temp file
Create a temporary keychain -- GitHub Actions runners have a default keychain, but importing into a fresh one avoids conflicts. The password is randomly generated for this build
Set it as the default -- so codesign uses it automatically
Configure keychain settings -- -lut 21600 sets a 6-hour lock timeout (enough for the longest build)
Unlock the keychain -- so signing doesn't prompt for a password
Import the certificate -- -A allows all apps to access it, -t cert -f pkcs12 specifies the format
Set partition list -- this is the critical step that allows codesign to access the imported key without a GUI prompt. Without this, signing fails silently.
Register the keychain -- adds it to the user's keychain search list
List identities -- a debugging aid that prints available signing identities in the build log

Why not let tauri-action handle the certificate import? You can -- tauri-action does support certificate import via its own inputs. But doing it explicitly gives you more control and better error messages when something goes wrong.

Build and Release

- name: Build and release
  uses: tauri-apps/tauri-action@v0
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    APPLE_CERTIFICATE: ${{ secrets.APPLE_CERTIFICATE }}
    APPLE_CERTIFICATE_PASSWORD: ${{ secrets.APPLE_CERTIFICATE_PASSWORD }}
    APPLE_SIGNING_IDENTITY: ${{ secrets.APPLE_SIGNING_IDENTITY }}
    APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
    APPLE_ID: ${{ secrets.APPLE_ID }}
    APPLE_PASSWORD: ${{ secrets.APPLE_PASSWORD }}
    TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
    TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
  with:
    tagName: v__VERSION__
    releaseName: "YourApp v__VERSION__"
    releaseBody: "See [CHANGELOG](https://github.com/YOUR_USERNAME/YOUR_REPO/blob/main/CHANGELOG.md) for details."
    releaseDraft: true
    prerelease: false
    args: ${{ matrix.args }}

tauri-action does the heavy lifting:

Runs npm run tauri build with the specified --target argument
Tauri compiles the Rust backend, bundles the frontend, and creates the installer
During bundling, Tauri calls codesign (macOS) or your signCommand (Windows) to sign the binaries
For macOS, Tauri submits the signed app to Apple for notarization and waits for the result
If createUpdaterArtifacts is enabled, it generates .sig files and latest.json
Creates (or updates) a draft GitHub Release for the tag
Uploads all artifacts to the release

Key with parameters:

Parameter	Purpose
`tagName`	`v__VERSION__` -- the `__VERSION__` placeholder is replaced with the version from `tauri.conf.json`
`releaseName`	Display name for the GitHub Release
`releaseBody`	Release description (we link to the changelog)
`releaseDraft`	`true` creates a draft release -- you review it before publishing
`prerelease`	Whether to mark it as a prerelease
`args`	Passed directly to `tauri build` (e.g., `--target aarch64-apple-darwin`)

Since all three matrix jobs reference the same tag, they all upload to the same draft release. The first job to run creates the release, and subsequent jobs add their artifacts.

Repository Settings

Workflow Permissions

By default, GITHUB_TOKEN has read-only permissions. You need to enable write access:

Go to your repository on GitHub
Settings > Actions > General
Scroll to Workflow permissions
Select Read and write permissions
Save

Adding Secrets

Go to Settings > Secrets and variables > Actions and add each secret:

macOS:

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_SIGNING_IDENTITY
APPLE_TEAM_ID
APPLE_ID
APPLE_PASSWORD

Windows:

AZURE_CLIENT_ID
AZURE_TENANT_ID
AZURE_CLIENT_SECRET

Updater:

TAURI_SIGNING_PRIVATE_KEY
TAURI_SIGNING_PRIVATE_KEY_PASSWORD

GITHUB_TOKEN is automatically provided by GitHub Actions -- you don't need to create it manually.

Release Automation Script

Now that CI is configured, you need a convenient way to trigger it. We'll build a shell script that:

Bumps the version in all three files (package.json, tauri.conf.json, Cargo.toml)
Regenerates Cargo.lock
Auto-generates a changelog from conventional commits
Creates a git commit and tag
Tells you to push

What It Does

The release flow is:

./scripts/release.sh patch
    |
    v
Bumps 0.1.0 -> 0.1.1 in package.json, tauri.conf.json, Cargo.toml
    |
    v
Regenerates Cargo.lock
    |
    v
Parses git log for conventional commits since last tag
    |
    v
Generates changelog entry and inserts into CHANGELOG.md
    |
    v
Creates commit: "chore: release v0.1.1"
    |
    v
Creates tag: v0.1.1
    |
    v
You run: git push origin main --tags
    |
    v
GitHub Actions triggers on the v* tag
    |
    v
Draft release appears with .dmg and .exe

The Script

Create scripts/release.sh:

#!/bin/bash

# Release Script
# Usage: ./scripts/release.sh [major|minor|patch|x.y.z]
#
# Automates the full release process:
#   1. Bumps version in package.json, tauri.conf.json, Cargo.toml
#   2. Regenerates Cargo.lock
#   3. Generates changelog from conventional commits since last tag
#   4. Creates a release commit and git tag
#
# The CI release workflow (.github/workflows/release.yml) triggers on tag push
# and builds cross-platform binaries automatically.

set -eo pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
DIM='\033[2m'
NC='\033[0m'

step() { printf '\n%b==>%b %s\n' "$BLUE" "$NC" "$1"; }
ok()   { printf '  %bok%b %s\n' "$GREEN" "$NC" "$1"; }
fail() { printf '  %berror%b %s\n' "$RED" "$NC" "$1"; exit 1; }

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
ROOT_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"

cd "$ROOT_DIR"

# ---------------------------------------------------------------------------
# Check required tools
# ---------------------------------------------------------------------------

for cmd in node cargo git; do
    command -v "$cmd" >/dev/null 2>&1 || fail "Required tool not found: $cmd"
done

# ---------------------------------------------------------------------------
# Parse arguments
# ---------------------------------------------------------------------------

if [ -z "${1:-}" ]; then
    echo "Usage: ./scripts/release.sh [major|minor|patch|x.y.z]"
    echo ""
    echo "Examples:"
    echo "  ./scripts/release.sh patch   # 0.1.8 -> 0.1.9"
    echo "  ./scripts/release.sh minor   # 0.1.8 -> 0.2.0"
    echo "  ./scripts/release.sh major   # 0.1.8 -> 1.0.0"
    echo "  ./scripts/release.sh 0.2.0   # explicit version"
    exit 1
fi

# ---------------------------------------------------------------------------
# Read current version from package.json
# ---------------------------------------------------------------------------

CURRENT_VERSION=$(node -p "require('./package.json').version")
IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"

case "$1" in
    major) NEW_VERSION="$((MAJOR + 1)).0.0" ;;
    minor) NEW_VERSION="${MAJOR}.$((MINOR + 1)).0" ;;
    patch) NEW_VERSION="${MAJOR}.${MINOR}.$((PATCH + 1))" ;;
    *)
        if [[ ! "$1" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
            fail "Invalid version format. Use x.y.z (e.g., 1.2.3)"
        fi
        NEW_VERSION="$1"
        ;;
esac

printf '%bRelease%b\n' "$BLUE" "$NC"
printf '  current : %b%s%b\n' "$DIM" "$CURRENT_VERSION" "$NC"
printf '  next    : %b%s%b\n' "$GREEN" "$NEW_VERSION" "$NC"
echo ""

# ---------------------------------------------------------------------------
# Pre-flight checks
# ---------------------------------------------------------------------------

step "Running pre-flight checks"

if [[ -n $(git status --porcelain) ]]; then
    fail "Uncommitted changes detected. Commit or stash them first."
fi
ok "Working tree clean"

CURRENT_BRANCH=$(git branch --show-current)
if [[ "$CURRENT_BRANCH" != "main" ]]; then
    printf '  %bwarning%b You are on branch '\''%s'\'', not '\''main'\''.\n' "$YELLOW" "$NC" "$CURRENT_BRANCH"
    read -p "  Continue anyway? (y/n) " -n 1 -r
    echo ""
    if [[ ! $REPLY =~ ^[Yy]$ ]]; then
        echo "Aborted."
        exit 0
    fi
else
    ok "On branch main"
fi

if git tag | grep -q "^v${NEW_VERSION}$"; then
    fail "Tag v${NEW_VERSION} already exists."
fi
ok "Tag v${NEW_VERSION} is available"

# ---------------------------------------------------------------------------
# Confirm
# ---------------------------------------------------------------------------

read -p "Proceed with release v${NEW_VERSION}? (y/n) " -n 1 -r
echo ""
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo "Aborted."
    exit 0
fi

# ---------------------------------------------------------------------------
# Bump versions
# ---------------------------------------------------------------------------

step "Updating version numbers"

node -e "
const fs = require('fs');
const version = '${NEW_VERSION}';

// package.json
const pkg = JSON.parse(fs.readFileSync('package.json', 'utf-8'));
pkg.version = version;
fs.writeFileSync('package.json', JSON.stringify(pkg, null, 2) + '\n');

// src-tauri/tauri.conf.json
const conf = JSON.parse(fs.readFileSync('src-tauri/tauri.conf.json', 'utf-8'));
conf.version = version;
fs.writeFileSync('src-tauri/tauri.conf.json', JSON.stringify(conf, null, 2) + '\n');

// src-tauri/Cargo.toml
const cargo = fs.readFileSync('src-tauri/Cargo.toml', 'utf-8');
fs.writeFileSync('src-tauri/Cargo.toml',
    cargo.replace(/^(version\s*=\s*)\"[^\"]*\"/m, \`\\\$1\"\${version}\"\`)
);
"
ok "package.json"
ok "src-tauri/tauri.conf.json"
ok "src-tauri/Cargo.toml"

# ---------------------------------------------------------------------------
# Regenerate Cargo.lock
# ---------------------------------------------------------------------------

step "Regenerating Cargo.lock"
(cd src-tauri && cargo generate-lockfile --quiet)
ok "Cargo.lock"

# ---------------------------------------------------------------------------
# Generate changelog entry and insert into CHANGELOG.md
# ---------------------------------------------------------------------------

step "Generating changelog"

LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
if [ -n "$LAST_TAG" ]; then
    RANGE="${LAST_TAG}..HEAD"
else
    RANGE="HEAD"
fi

TODAY=$(date +%Y-%m-%d)

CHANGELOG_ENTRY=$(node -e "
const { execSync } = require('child_process');
const fs = require('fs');

const range = '${RANGE}';
const version = '${NEW_VERSION}';
const today = '${TODAY}';

// Parse conventional commits
const log = execSync(
    'git log ' + range + ' --pretty=format:\"%s\" --reverse',
    { encoding: 'utf-8' }
);
const lines = log.split('\n').filter(Boolean);

const added = [];
const fixed = [];
const changed = [];

const pattern = /^(feat|fix|refactor|perf|build|style|docs|test|chore)(\(.*?\))?\!?:\s(.+)$/;

for (const line of lines) {
    const m = line.match(pattern);
    if (!m) continue;
    const [, type, scope, msg] = m;
    const entry = scope
        ? '**' + scope.slice(1, -1) + '**: ' + msg
        : msg;
    switch (type) {
        case 'feat': added.push(entry); break;
        case 'fix': fixed.push(entry); break;
        case 'refactor': case 'perf': case 'style': changed.push(entry); break;
    }
}

// Build changelog section
let entry = '## [' + version + '] - ' + today;
let hasContent = false;

if (added.length) {
    entry += '\n\n### Added\n\n' + added.map(e => '- ' + e).join('\n');
    hasContent = true;
}
if (fixed.length) {
    entry += '\n\n### Fixed\n\n' + fixed.map(e => '- ' + e).join('\n');
    hasContent = true;
}
if (changed.length) {
    entry += '\n\n### Changed\n\n' + changed.map(e => '- ' + e).join('\n');
    hasContent = true;
}
if (!hasContent) {
    entry += '\n\nMaintenance release.';
}

// Insert into CHANGELOG.md
const changelog = fs.readFileSync('CHANGELOG.md', 'utf-8');
const marker = '\n## [';
const idx = changelog.indexOf(marker);

if (idx !== -1) {
    const before = changelog.slice(0, idx);
    const after = changelog.slice(idx);
    fs.writeFileSync('CHANGELOG.md', before + '\n\n' + entry + '\n' + after);
} else {
    fs.writeFileSync('CHANGELOG.md', changelog.trimEnd() + '\n\n' + entry + '\n');
}

// Output entry for preview
process.stdout.write(entry);
")

ok "CHANGELOG.md"

# Show the generated changelog for review
echo ""
printf '%b--- changelog preview ---%b\n' "$DIM" "$NC"
echo "$CHANGELOG_ENTRY"
printf '%b--- end preview ---%b\n' "$DIM" "$NC"
echo ""

read -p "Does the changelog look good? (y/n) " -n 1 -r
echo ""
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo ""
    echo "Edit CHANGELOG.md manually, then run:"
    echo "  git add package.json src-tauri/Cargo.toml src-tauri/Cargo.lock src-tauri/tauri.conf.json CHANGELOG.md"
    echo "  git commit -m \"chore: release v${NEW_VERSION}\""
    echo "  git tag -a v${NEW_VERSION} -m \"Release v${NEW_VERSION}\""
    echo "  git push origin main --tags"
    exit 0
fi

# ---------------------------------------------------------------------------
# Git commit and tag
# ---------------------------------------------------------------------------

step "Creating release commit"

git add package.json src-tauri/Cargo.toml src-tauri/Cargo.lock src-tauri/tauri.conf.json CHANGELOG.md
git commit -m "chore: release v${NEW_VERSION}"
ok "Committed"

step "Creating tag v${NEW_VERSION}"
git tag -a "v${NEW_VERSION}" -m "Release v${NEW_VERSION}"
ok "Tagged"

# ---------------------------------------------------------------------------
# Done
# ---------------------------------------------------------------------------

echo ""
printf '%b========================================%b\n' "$GREEN" "$NC"
printf '%b  Released v%s%b\n' "$GREEN" "$NEW_VERSION" "$NC"
printf '%b========================================%b\n' "$GREEN" "$NC"
echo ""
echo "Next steps:"
echo "  1. Review the commit:  git show HEAD"
echo "  2. Push to trigger CI: git push origin main --tags"
echo ""
echo "  CI will build cross-platform binaries and create a draft GitHub release."
echo ""
echo "To undo this release:"
echo "  git tag -d v${NEW_VERSION} && git reset --soft HEAD~1"

Make it executable:

chmod +x scripts/release.sh

How the Script Works

Let's break down the key parts.

Version Bumping

The script updates version strings in three files simultaneously:

package.json -- the canonical version source, also used by npm
src-tauri/tauri.conf.json -- Tauri reads this for the app version. The __VERSION__ placeholder in your workflow's tagName: v__VERSION__ is resolved from here.
src-tauri/Cargo.toml -- the Rust crate version. Must match for consistency.

All three must stay in sync. The script uses a single node -e invocation to update all of them atomically.

Cargo.lock Regeneration

After bumping Cargo.toml, the lockfile is out of date:

(cd src-tauri && cargo generate-lockfile --quiet)

This regenerates it without compiling anything. If you skip this step, CI will see a lockfile mismatch and may produce unexpected results.

Changelog Generation

The script parses your git history using conventional commits:

Prefix	Changelog Section
`feat:`	Added
`fix:`	Fixed
`refactor:`, `perf:`, `style:`	Changed
`chore:`, `docs:`, `test:`, `build:`	Skipped

Scoped commits like feat(ui): add dark mode become **ui**: add dark mode in the changelog.

The generated entry is inserted into CHANGELOG.md before the previous version, maintaining the reverse-chronological order expected by Keep a Changelog.

You get a preview and a chance to bail out and edit manually before the commit is created.

Safe Pre-flight Checks

Before doing anything destructive, the script verifies:

Working tree is clean -- no uncommitted changes that would be included accidentally
Branch check -- warns if you're not on main (you might be on a feature branch by accident)
Tag availability -- confirms the target tag doesn't already exist

The Undo Escape Hatch

If something went wrong:

git tag -d v0.1.1 && git reset --soft HEAD~1

This deletes the local tag and undoes the commit while keeping your changes staged. Clean recovery.

npm Script Entry Point

Add this to your package.json for convenience:

{
  "scripts": {
    "release:new": "bash scripts/release.sh"
  }
}

Usage:

npm run release:new -- patch    # 0.1.0 -> 0.1.1
npm run release:new -- minor    # 0.1.0 -> 0.2.0
npm run release:new -- major    # 0.1.0 -> 1.0.0
npm run release:new -- 2.0.0    # explicit version

The Full Release Flow

Here's the complete end-to-end process:

1. Prepare

Make sure all your changes are committed and pushed. The release script requires a clean working tree.

git status  # Should be clean

2. Run the Release Script

npm run release:new -- patch

Output looks like:

Release
  current : 0.2.0
  next    : 0.3.0

==> Running pre-flight checks
  ok Working tree clean
  ok On branch main
  ok Tag v0.3.0 is available
Proceed with release v0.3.0? (y/n) y

==> Updating version numbers
  ok package.json
  ok src-tauri/tauri.conf.json
  ok src-tauri/Cargo.toml

==> Regenerating Cargo.lock
  ok Cargo.lock

==> Generating changelog
  ok CHANGELOG.md

--- changelog preview ---
## [0.3.0] - 2026-02-19

### Added

- **ui**: add dark mode toggle
- **i18n**: add Japanese translations

### Fixed

- **auth**: fix PIN validation edge case
--- end preview ---

Does the changelog look good? (y/n) y

==> Creating release commit
  ok Committed

==> Creating tag v0.3.0
  ok Tagged

========================================
  Released v0.3.0
========================================

Next steps:
  1. Review the commit:  git show HEAD
  2. Push to trigger CI: git push origin main --tags

3. Review and Push

git show HEAD         # Review the release commit
git push origin main --tags  # Trigger CI

4. Monitor the Build

Go to your repository's Actions tab. You'll see three jobs running:

release (macos-latest, aarch64-apple-darwin) -- ~10-15 min
release (macos-latest, x86_64-apple-darwin) -- ~10-15 min
release (windows-latest, x86_64-pc-windows-msvc) -- ~8-12 min

The macOS builds take longer because of the notarization step -- Tauri uploads the signed app to Apple and waits for the response.

5. Review the Draft Release

Once all three jobs complete, go to Releases in your repository. You'll find a draft release with:

YourApp_0.3.0_aarch64.dmg -- macOS Apple Silicon installer
YourApp_0.3.0_x64.dmg -- macOS Intel installer
YourApp_0.3.0_x64-setup.exe -- Windows installer
YourApp_0.3.0_x64-setup.nsis.zip -- Windows NSIS archive
latest.json -- Updater manifest
.sig files -- Updater signatures

Edit the release notes if needed, then click Publish release.

Verifying Your Release

macOS Verification

Download the .dmg and check that the app is properly signed and notarized:

# Check code signing
codesign --verify --deep --strict /Applications/YourApp.app

# Check notarization
spctl -a -v /Applications/YourApp.app

The spctl command should output:

/Applications/YourApp.app: accepted
source=Notarized Developer ID

If you see "rejected", the notarization failed. Check the CI build logs for errors.

Windows Verification

On Windows, right-click the .exe installer > Properties > Digital Signatures tab. You should see your certificate listed.

If SmartScreen still shows a warning, your certificate is new and hasn't built reputation yet. This improves over time as more users install your app. You can accelerate this by submitting your binary to Microsoft's file submission portal.

Troubleshooting

"Resource not accessible by integration"

Your GITHUB_TOKEN doesn't have write permissions. Go to Settings > Actions > General > Workflow permissions and enable Read and write permissions.

macOS: "No signing identity found"

The certificate wasn't imported correctly. Common causes:

APPLE_CERTIFICATE secret doesn't contain valid base64
APPLE_CERTIFICATE_PASSWORD is wrong
The certificate has expired

Check the "Import Apple signing certificate" step output -- it prints available identities. If the list is empty, the import failed.

macOS: Notarization fails with "invalid credentials"

Verify APPLE_ID is your Apple account email
Verify APPLE_PASSWORD is an app-specific password, not your Apple ID password
Verify APPLE_TEAM_ID is correct (check your membership page)
Make sure 2FA is enabled on your Apple ID (required for app-specific passwords)

Windows: "relic: command not found"

Relic needs to be installed on the Windows runner. Add this step before the build:

- name: Install relic
  if: runner.os == 'Windows'
  run: go install github.com/sassoftware/relic/v8@latest

Go is pre-installed on GitHub Actions Windows runners.

Windows: Azure Key Vault 403 / access denied

Check that your App Registration has both required roles on the Key Vault:

Key Vault Certificate User
Key Vault Crypto User

Also verify that the AZURE_CLIENT_SECRET hasn't expired.

Build succeeds but no artifacts on the release

This usually means the tagName doesn't match. The v__VERSION__ placeholder is replaced with the version from tauri.conf.json. If you tagged v0.3.0 but tauri.conf.json says 0.2.0, the action creates a release for v0.2.0 (which doesn't match your tag) and things get confused.

Always use the release script to keep versions in sync.

Slow builds

First builds are the slowest because there's no Rust compilation cache. The swatinem/rust-cache@v2 action caches the target/ directory, so subsequent builds should be significantly faster.

For macOS, notarization adds 2-5 minutes per build. There's no way around this -- Apple needs time to scan your binary.

Conclusion

Here's what we've set up across both parts:

macOS code signing with a Developer ID Application certificate
macOS notarization via Apple ID + app-specific password
Windows code signing via Azure Key Vault + relic
Tauri updater signing for secure in-app updates
GitHub Actions workflow that builds for 3 targets (macOS ARM, macOS Intel, Windows x64)
Release automation script that bumps versions, generates changelogs, and creates tags
Draft releases for review before publishing

The result: run npm run release:new -- patch, push, wait ~15 minutes, review the draft, and publish. Your users get signed, notarized, verified installers on every platform.

The entire pipeline shown here is used in production by Fortuna, an open-source personal wealth management app built with Tauri v2. Feel free to browse the repository for the full implementation and to participate in the project with a PR if you wish!

Quick Reference

# One-time setup
# 1. Create Apple Developer ID certificate (see Part 1)
# 2. Set up Azure Key Vault for Windows signing (see Part 1)
# 3. Generate Tauri updater keys:
npx tauri signer generate -w ~/.tauri/myapp.key
# 4. Add all 11 secrets to GitHub (see Part 1 summary)
# 5. Enable Actions write permissions in repo settings

# Every release
npm run release:new -- patch       # or minor, major, x.y.z
git push origin main --tags        # triggers CI
# Wait for builds, review draft release, publish

Ship Your Tauri v2 App Like a Pro: Code Signing for macOS and Windows (Part 1/2)

Thomas Cosialls — Fri, 20 Feb 2026 05:19:44 +0000

You've built a Tauri desktop app. It compiles, it runs, your friends are impressed. Nice! Then you send the .dmg to someone and macOS says "this app is damaged and can't be opened." Or Windows SmartScreen blocks the .exe entirely. Welcome to the world of code signing.

This two-part guide walks you through the entire release pipeline for a Tauri v2 application -- from code signing certificates to automated cross-platform builds on GitHub Actions. It's based on real-world experience shipping Fortuna, an open-source offline wealth management desktop app built with Tauri v2, React, and Rust.

Part 1 (this article) covers code signing setup for macOS and Windows.
Part 2 covers GitHub Actions CI/CD, release automation scripts, and the updater.

By the end, pushing a git tag will automatically build signed .dmg and .exe installers and publish them as a GitHub Release.

Prerequisites
Project Configuration Baseline
macOS Code Signing
- Apple Developer Account
- Create a Developer ID Certificate
- Find Your Signing Identity
- Create an Entitlements File
- Configure tauri.conf.json for macOS
- Set Up Notarization
- Export Your Certificate for CI
Windows Code Signing
- Why Azure Key Vault?
- Create an Azure Account
- Set Up Azure Key Vault
- Create an App Registration
- Assign Permissions
- Install relic
- Create the relic Configuration
- Configure tauri.conf.json for Windows
Tauri Updater Signing
- Generate an Update Signing Keypair
- Configure the Updater
Summary of Secrets
What's Next

Prerequisites

Before you start, make sure you have:

A working Tauri v2 project that builds locally (npm run tauri build)
Node.js (LTS)
Rust (stable toolchain)
A macOS machine (required for Apple certificate creation)
A GitHub repository for your project
Some patience -- there are a lot of accounts and portals involved

Project Configuration Baseline

Your src-tauri/tauri.conf.json should already have the basic bundle configuration. Here's what the relevant skeleton looks like before we add signing:

{
  "$schema": "https://schema.tauri.app/config/2",
  "productName": "YourApp",
  "version": "0.1.0",
  "identifier": "com.yourcompany.yourapp",
  "build": {
    "beforeDevCommand": "npm run dev",
    "devUrl": "http://localhost:1420",
    "beforeBuildCommand": "npm run build",
    "frontendDist": "../dist"
  },
  "bundle": {
    "active": true,
    "targets": ["app", "dmg", "nsis"],
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/128x128@2x.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ],
    "category": "Finance",
    "shortDescription": "Your app description",
    "macOS": {},
    "windows": {}
  }
}

The targets array tells Tauri what to produce:

"app" -- the .app bundle on macOS
"dmg" -- the macOS disk image installer
"nsis" -- the Windows .exe installer (NSIS-based)

We'll fill in the macOS and windows sections as we go.

macOS Code Signing

Apple requires apps distributed outside the App Store to be code signed and notarized. Without both, macOS will either show scary warnings or outright refuse to open your app.

1. Apple Developer Account

You need a paid Apple Developer account ($99/year) from developer.apple.com. The free tier lets you develop and test but cannot notarize apps -- meaning users will see the "damaged app" dialog.

Enroll at: developer.apple.com/programs/enroll

2. Create a Developer ID Certificate

A Developer ID Application certificate is what you need for apps distributed outside the Mac App Store.

Only the Account Holder role can create Developer ID certificates. If you're on a team, the account holder needs to do this step.

Steps:

On your Mac, open Keychain Access
Go to Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority
Enter your email, leave CA Email blank, select Saved to disk, and save the .certSigningRequest file
Go to Apple Developer > Certificates
Click the + button to create a new certificate
Select Developer ID Application and click Continue
Upload your .certSigningRequest file
Download the generated .cer file
Double-click the .cer file to install it in your keychain (make sure the login keychain is selected)

3. Find Your Signing Identity

After installing the certificate, find the exact identity string:

security find-identity -v -p codesigning

You'll see output like:

1) ABC123DEF456... "Developer ID Application: Your Name (TEAMID)"

The quoted string is your signing identity. Note it down -- you'll need it for tauri.conf.json and as a GitHub secret.

4. Create an Entitlements File

Tauri apps use a WebView that requires JIT compilation. Create src-tauri/Entitlements.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
</dict>
</plist>

These two entitlements are required for the WebView to function:

allow-jit -- enables Just-In-Time compilation
allow-unsigned-executable-memory -- allows the JavaScript engine to allocate executable memory

5. Configure tauri.conf.json for macOS

Add the macOS signing configuration to your bundle section:

{
  "bundle": {
    "macOS": {
      "signingIdentity": "Developer ID Application: Your Name (TEAMID)",
      "entitlements": "./Entitlements.plist",
      "minimumSystemVersion": "11.0",
      "dmg": {
        "appPosition": { "x": 180, "y": 170 },
        "applicationFolderPosition": { "x": 480, "y": 170 }
      }
    }
  }
}

Field breakdown:

Field	Purpose
`signingIdentity`	The identity string from step 3. Can also be set via `APPLE_SIGNING_IDENTITY` env var.
`entitlements`	Path to the entitlements plist (relative to `src-tauri/`).
`minimumSystemVersion`	Minimum macOS version. `"11.0"` (Big Sur) is a reasonable floor for modern apps.
`dmg.appPosition`	Where the app icon sits in the DMG installer window.
`dmg.applicationFolderPosition`	Where the "Applications" shortcut sits in the DMG.

The DMG position values control the drag-to-install layout that users see when they open the .dmg file.

6. Set Up Notarization

Notarization is Apple's automated security check. It's separate from code signing -- after Tauri signs your app, it uploads the binary to Apple's servers for analysis. If it passes, Apple staples a "ticket" to your app so macOS trusts it.

Tauri handles notarization automatically during the build process. You just need to provide credentials via environment variables.

Option A: Apple ID + App-Specific Password (simpler)

This is the approach most indie developers use.

Go to appleid.apple.com > Sign-In and Security > App-Specific Passwords
Generate a new app-specific password (name it something like "Tauri Notarization")
Find your Team ID at developer.apple.com/account under Membership Details

The environment variables you'll need:

Variable	Value
`APPLE_ID`	Your Apple account email
`APPLE_PASSWORD`	The app-specific password (NOT your Apple ID password)
`APPLE_TEAM_ID`	Your 10-character Team ID

Option B: App Store Connect API Key (more secure, recommended for teams)

Go to App Store Connect > Users and Access > Integrations > Keys
Click + to create a new key with Developer access
Download the .p8 private key file (you can only download it once)
Note the Key ID and Issuer ID

Variable	Value
`APPLE_API_ISSUER`	The Issuer ID shown above the keys table
`APPLE_API_KEY`	The Key ID from the table
`APPLE_API_KEY_PATH`	Path to the downloaded `.p8` key file

This guide uses Option A for simplicity. Either way works with Tauri's built-in notarization.

7. Export Your Certificate for CI

Your Mac has the certificate in its keychain, but GitHub Actions runners need it too. You'll export it as a base64-encoded .p12 file.

Open Keychain Access
Click My Certificates in the left sidebar (under "login" keychain)
Find your "Developer ID Application" certificate
Expand it (click the arrow) -- you should see a private key underneath
Right-click the private key and select Export
Save as .p12 format and set a strong password
Convert to base64:

base64 -i certificate.p12 -o certificate-base64.txt

Open certificate-base64.txt -- this is the value for the APPLE_CERTIFICATE secret

Security note: Delete the .p12 and certificate-base64.txt files after you've stored them as GitHub secrets. Never commit these files to your repository.

macOS secrets summary:

GitHub Secret	Value
`APPLE_CERTIFICATE`	Base64 content of the exported `.p12` file
`APPLE_CERTIFICATE_PASSWORD`	Password you set during `.p12` export
`APPLE_SIGNING_IDENTITY`	e.g., `Developer ID Application: Your Name (TEAMID)`
`APPLE_TEAM_ID`	Your 10-character Team ID
`APPLE_ID`	Your Apple account email
`APPLE_PASSWORD`	App-specific password for notarization

Windows Code Signing

Windows code signing prevents SmartScreen from blocking your installer and tells users that your app comes from a verified publisher.

Why Azure Key Vault?

Since June 2023, certificate authorities no longer issue OV (Organization Validation) code signing certificates on exportable files. New certificates must be stored on hardware security modules (HSMs). The most accessible option for indie developers and small teams is Azure Key Vault, which acts as a cloud-based HSM.

We'll use relic, an open-source signing tool that can authenticate to Azure Key Vault and sign Windows executables.

Alternative: Azure Trusted Signing is another option, but it requires a more involved setup with Azure Code Signing accounts and profiles. The Key Vault approach is more straightforward.

1. Create an Azure Account

Sign up at portal.azure.com. You'll need an active subscription -- the Pay-As-You-Go plan works fine. Key Vault costs are minimal (a few cents per signing operation).

2. Set Up Azure Key Vault

In the Azure Portal, search for Key Vault and create one
Pick a name (e.g., app-signing-tauri), choose your region, select the Standard pricing tier
Create the vault
Navigate to your vault > Objects > Certificates
Click Generate/Import to create a new certificate:
- Method: Generate
- Certificate Name: e.g., your-app-signing
- Type of CA: Self-signed (or integrate with a CA if you have one)
- Subject: CN=Your Company Name
- Validity Period: 12 months (or your preference)
- Content Type: PKCS #12
Click Create and wait for it to provision

Note on self-signed vs CA-issued: A self-signed certificate from Azure Key Vault will still trigger SmartScreen warnings initially. To avoid this entirely, you need an EV (Extended Validation) certificate from a trusted CA stored in Key Vault. For most indie apps, SmartScreen reputation builds over time as more users install your app. You can also manually submit your binary to Microsoft's file submission portal to speed this up.

3. Create an App Registration

Azure Key Vault uses Azure Active Directory for authentication. You need an "App Registration" -- essentially a service account.

In the Azure Portal, go to Microsoft Entra ID (formerly Azure Active Directory)
Navigate to App registrations > New registration
Name it (e.g., tauri-code-signing)
Leave the redirect URI blank
Click Register
Note the Application (client) ID -- this is your AZURE_CLIENT_ID
Note the Directory (tenant) ID -- this is your AZURE_TENANT_ID
Go to Certificates & secrets > Client secrets > New client secret
Set a description and expiration
Click Add and immediately copy the Value -- this is your AZURE_CLIENT_SECRET

The client secret value is only shown once. Copy it now or you'll need to create a new one.

4. Assign Permissions

Your app registration needs permission to use the Key Vault for signing.

Go to your Key Vault in the Azure Portal
Navigate to Access control (IAM)
Click Add role assignment
Assign these two roles to your app registration:
- Key Vault Certificate User -- allows reading the certificate
- Key Vault Crypto User -- allows signing operations

Without both roles, signing will fail with a permissions error.

5. Install relic

Relic is a Go-based signing tool that bridges Azure Key Vault and the code signing process.

go install github.com/sassoftware/relic/v8@latest

Make sure $GOPATH/bin is in your PATH. Verify with:

relic --version

On the GitHub Actions Windows runner, Go is pre-installed. You'll install relic as a build step (covered in Part 2).

6. Create the relic Configuration

Create src-tauri/relic.conf:

tokens:
  azure:
    type: azure

keys:
  azure:
    token: azure
    id: https://<YOUR_VAULT_NAME>.vault.azure.net/certificates/<YOUR_CERTIFICATE_NAME>

Replace:

<YOUR_VAULT_NAME> with your Key Vault name (e.g., app-signing-tauri)
<YOUR_CERTIFICATE_NAME> with your certificate name (e.g., your-app-signing)

This file is safe to commit -- it contains no secrets, only the vault and certificate identifiers. Authentication happens via environment variables at runtime.

7. Configure tauri.conf.json for Windows

Add the Windows signing configuration to your bundle section:

{
  "bundle": {
    "windows": {
      "signCommand": "relic sign --file %1 --key azure --config relic.conf",
      "webviewInstallMode": {
        "type": "downloadBootstrapper"
      },
      "nsis": {
        "installMode": "both"
      }
    }
  }
}

Field breakdown:

Field	Purpose
`signCommand`	Custom signing command. `%1` is replaced by the file path to sign. Tauri calls this for every binary and the installer.
`webviewInstallMode`	How the installer handles the WebView2 runtime. `"downloadBootstrapper"` downloads it on demand, keeping your installer small.
`nsis.installMode`	`"both"` means the installer can run as both per-user and per-machine.

The signCommand approach is the most flexible -- Tauri will invoke this command for every file that needs signing, passing the file path as %1. Relic then authenticates to Azure using the AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET environment variables and signs the file using the Key Vault certificate.

Windows secrets summary:

GitHub Secret	Value
`AZURE_CLIENT_ID`	Application (client) ID from App Registration
`AZURE_TENANT_ID`	Directory (tenant) ID from App Registration
`AZURE_CLIENT_SECRET`	Client secret value from App Registration

Tauri Updater Signing

If you plan to use Tauri's built-in auto-updater, you need a separate signing keypair. This is unrelated to OS-level code signing -- it's used to verify that update payloads come from you and haven't been tampered with.

1. Generate an Update Signing Keypair

Run the Tauri CLI to generate a keypair:

npx tauri signer generate -w ~/.tauri/myapp.key

This creates two files:

~/.tauri/myapp.key -- your private key (keep this secret)
~/.tauri/myapp.key.pub -- your public key (embed this in your app)

The CLI will prompt you for an optional password. If you set one, you'll need to provide it as TAURI_SIGNING_PRIVATE_KEY_PASSWORD.

Store the private key securely and never commit it. The public key is safe to embed in your app config.

2. Configure the Updater

Add the updater plugin configuration to tauri.conf.json:

{
  "bundle": {
    "createUpdaterArtifacts": true
  },
  "plugins": {
    "updater": {
      "endpoints": [
        "https://github.com/YOUR_USERNAME/YOUR_REPO/releases/latest/download/latest.json"
      ],
      "pubkey": "YOUR_PUBLIC_KEY_CONTENT_HERE"
    }
  }
}

Field breakdown:

Field	Purpose
`createUpdaterArtifacts`	Tells the build to generate the `.sig` signature files and `latest.json` manifest alongside the installer.
`endpoints`	Where your app checks for updates. The GitHub Releases URL is the simplest approach.
`pubkey`	The content of your `.key.pub` file. Used by the app to verify update signatures.

The tauri-action in your CI workflow will automatically upload the latest.json file to the GitHub Release, which the updater plugin reads to detect available updates.

Updater secrets:

GitHub Secret	Value
`TAURI_SIGNING_PRIVATE_KEY`	Content of the private key file (`~/.tauri/myapp.key`)
`TAURI_SIGNING_PRIVATE_KEY_PASSWORD`	Password for the key (if you set one)

Summary of Secrets

Here's the complete list of GitHub secrets you'll need to configure in your repository (Settings > Secrets and variables > Actions):

macOS Signing + Notarization

Secret	Description
`APPLE_CERTIFICATE`	Base64-encoded `.p12` certificate
`APPLE_CERTIFICATE_PASSWORD`	Password for the `.p12` file
`APPLE_SIGNING_IDENTITY`	e.g., `Developer ID Application: Your Name (TEAMID)`
`APPLE_TEAM_ID`	10-character Team ID from Apple Developer portal
`APPLE_ID`	Apple account email for notarization
`APPLE_PASSWORD`	App-specific password for notarization

Windows Signing (Azure Key Vault)

Secret	Description
`AZURE_CLIENT_ID`	App Registration client ID
`AZURE_TENANT_ID`	Azure directory tenant ID
`AZURE_CLIENT_SECRET`	App Registration client secret

Tauri Updater

Secret	Description
`TAURI_SIGNING_PRIVATE_KEY`	Private key for update signing
`TAURI_SIGNING_PRIVATE_KEY_PASSWORD`	Password for the key (if set)

Total: 11 secrets. Yes, it's a lot. The good news is you only set them up once.

Complete tauri.conf.json

Here's what the full bundle section looks like with everything configured:

{
  "$schema": "https://schema.tauri.app/config/2",
  "productName": "YourApp",
  "version": "0.1.0",
  "identifier": "com.yourcompany.yourapp",
  "build": {
    "beforeDevCommand": "npm run dev",
    "devUrl": "http://localhost:1420",
    "beforeBuildCommand": "npm run build",
    "frontendDist": "../dist"
  },
  "app": {
    "windows": [
      {
        "title": "YourApp",
        "width": 1200,
        "height": 800,
        "resizable": true
      }
    ],
    "security": {
      "csp": "default-src 'self'; style-src 'self' 'unsafe-inline'"
    }
  },
  "bundle": {
    "createUpdaterArtifacts": true,
    "active": true,
    "targets": ["app", "dmg", "nsis"],
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/128x128@2x.png",
      "icons/icon.icns",
      "icons/icon.ico"
    ],
    "category": "Finance",
    "shortDescription": "Your app description",
    "macOS": {
      "signingIdentity": "Developer ID Application: Your Name (TEAMID)",
      "entitlements": "./Entitlements.plist",
      "minimumSystemVersion": "11.0",
      "dmg": {
        "appPosition": { "x": 180, "y": 170 },
        "applicationFolderPosition": { "x": 480, "y": 170 }
      }
    },
    "windows": {
      "signCommand": "relic sign --file %1 --key azure --config relic.conf",
      "webviewInstallMode": { "type": "downloadBootstrapper" },
      "nsis": { "installMode": "both" }
    }
  },
  "plugins": {
    "updater": {
      "endpoints": [
        "https://github.com/YOUR_USERNAME/YOUR_REPO/releases/latest/download/latest.json"
      ],
      "pubkey": "YOUR_PUBLIC_KEY_HERE"
    }
  }
}

What's Next

At this point you have:

A macOS signing certificate ready for CI
Azure Key Vault configured for Windows signing
Updater signing keys generated
All 11 secrets identified and ready to add to GitHub

In Part 2, we'll wire all of this into a GitHub Actions workflow that:

Builds your app for macOS (ARM + Intel) and Windows
Signs and notarizes automatically
Uploads installers to a draft GitHub Release
Generates updater artifacts for in-app updates

We'll also build a release automation script that bumps versions, generates changelogs, and triggers the whole pipeline with a single command.

Continue to Part 2: GitHub Actions and Release Automation ->

Collecting Fees and Rewards from Orca Whirlpool Positions

Thomas Cosialls — Thu, 27 Nov 2025 05:26:48 +0000

A quick guide using Anchor and the whirlpool_cpi crate

What You'll Learn

Orca Whirlpools is a concentrated liquidity AMM on Solana. When you provide liquidity, you earn:

Trading Fees: A share of swaps within your price range (Token A + Token B)
Rewards: Up to 3 incentive tokens configured by the pool operator

This guide shows how to collect both programmatically using CPI.

The Critical Step Everyone Misses

You must call update_fees_and_rewards before collecting, or you will receive 0 tokens.

The position account stores fees/rewards as checkpoints. The update instruction calculates what's owed since the last checkpoint and writes it to fee_owed_a, fee_owed_b, and reward_infos[].amount_owed. Without this step, those fields remain at zero.

// CRITICAL: Always call this BEFORE collect_fees or collect_reward
execute_update_fees_and_rewards_cpi(
    &ctx.accounts.whirlpool_program,
    &ctx.accounts.whirlpool.to_account_info(),
    &ctx.accounts.position.to_account_info(),
    &ctx.accounts.tick_array_lower.to_account_info(),
    &ctx.accounts.tick_array_upper.to_account_info(),
    Some(vault_seeds),
)?;

Collecting Fees

After updating, call collect_fees to receive both pool tokens:

whirlpool_cpi::cpi::collect_fees(cpi_ctx)?;

Collecting Rewards

Rewards use an index-based system (0, 1, or 2). Check whirlpool.rewardInfos[index] for active rewards:

// Client-side: iterate through active reward slots
for (let rewardIndex = 0; rewardIndex < 3; rewardIndex++) {
  const rewardInfo = pool_data.data.rewardInfos[rewardIndex]

  // Skip uninitialized slots
  if (rewardInfo.mint.toString() === "11111111111111111111111111111111") {
    continue
  }

  // Collect this reward using its index, mint, and vault
  await program.methods
    .collectRewardsOrcaPosition(operationId, rewardIndex)
    .accounts({
      rewardTokenMint: rewardInfo.mint,
      rewardVault: rewardInfo.vault,
      // ... other accounts
    })
    .rpc()
}

Quick Summary

Always update first - Call update_fees_and_rewards or get 0 tokens
Fees are both tokens - One call collects Token A and Token B
Rewards are per-index - Loop through rewardInfos[0..2] and collect each active one

📖 Read the full guide for complete CPI implementations, account structures, and client-side fee/reward quote calculations using the Orca SDK.

🌐 AI Agents: The Silent Revolution in Your Tech Stack (That’s About to Get Loud)

Thomas Cosialls — Mon, 24 Feb 2025 22:03:26 +0000

Imagine tools that don’t just follow orders—but debate, adapt, and even outthink you. Spoiler: They’re already here.

AI agents aren’t coming. They’re colonizing workflows, and your business is either riding the wave or drowning in legacy code. Forget clunky bots—these are digital alchemists turning:

Chaos into strategy (Autonomous multi-step planning)
Data into intuition (Context-aware memory that learns)
Silos into symphonies (Seamless tool integration)

“But wait—can they handle REAL work?”
Ask the blockchain devs automating 80% of audits. Or the support teams sleeping through peak hours while their AI clones charm customers.

The kicker? This isn’t sci-fi—it’s 2024’s open-source reality. By the time you finish this teaser, another startup just deployed an agent that codes better than their interns.

“Show me the future before I’m obsolete” → Read full article here

Building SpyClub: A Modern Telegram Mini App with Web3 Features 🚀

Thomas Cosialls — Wed, 05 Feb 2025 22:56:10 +0000

Ever wondered how to create a blockchain-enabled game that runs smoothly within Telegram? Let's explore how we built SpyClub, a multiplayer word game that combines real-time gaming with crypto rewards!

What Makes SpyClub Special? 🎮

SpyClub isn't your typical word game. Players compete in real-time matches, earning $Spycoin tokens while climbing leaderboards, with top performers receiving USDC rewards. It's where casual gaming meets Web3!

Technical Breakdown ⚡

Here's our powerful tech stack:

Frontend:

React with Vite for lightning-fast performance
Zustand for state management
Tailwind CSS with shadcn/ui for slick UI
Telegram Mini App SDK for platform integration

Backend:

Fastify for high-performance API handling
Supabase for database and real-time features
Hedera for blockchain transactions

Key Features in Action 💫

Let's peek at some real implementation highlights:

// Game Room Management
export class GameRoom {
  private async startRound(round: number) {
    const wordSet = await this.getNewWordSet()

    this.channel.send({
      type: 'broadcast',
      event: 'game_update',
      payload: {
        type: 'new_round',
        round,
        clue: wordSet.clue,
        words: allWords,
        endTime: roundEndTime,
      },
    })
  }
}

Real-time Magic ✨

The game stays synchronized using Supabase's real-time channels, managing everything from player moves to score updates. We handle blockchain rewards through Hedera, ensuring secure and transparent token distribution.

Pro Tips for Mini App Development 💡

Always validate Telegram authentication data
Handle real-time state synchronization carefully
Implement retry mechanisms for blockchain operations
Optimize for mobile-first experience

Why This Architecture Works 🎯

-Scalable multiplayer system

Secure blockchain integration
Smooth user experience
Real-time performance

Ready to Build Your Own? 🚀

Whether you're creating a game, a DeFi app, or something entirely new, the patterns we've shared can jumpstart your Telegram Mini App development journey.

Want to learn more about building blockchain-enabled applications? Let's connect and turn your ideas into reality!

Implementing SIWE with WalletConnect's AppKit in Next.js

Thomas Cosialls — Fri, 23 Aug 2024 03:34:11 +0000

Web3 authentication is evolving, and Sign In With Ethereum (SIWE) is leading the charge. This article explores how to implement SIWE in a Next.js application using WalletConnect's AppKit, focusing on the "One Click Auth" feature and securing API routes with JWT tokens.

Understanding SIWE and AppKit

Sign In With Ethereum (SIWE) is a standardized authentication method (EIP-4361) that allows users to prove ownership of their Ethereum address through a cryptographic signature. WalletConnect's AppKit simplifies this process with its "One-Click Auth" feature, enhancing both security and user experience.

Implementation Steps

Set up: Install necessary dependencies:

   yarn add @web3modal/siwe next-auth

Configure SIWE Client: Create a SIWE client configuration file to handle message parameters, nonce generation, and session management.
Set Up API Route: Implement a NextAuth handler to manage authentication, verifying signatures and creating sessions using JWT tokens.
Secure API Routes: Use a Next.js middleware to protect specified routes, requiring authentication for access and passing the user's wallet address to API routes.

Read this article for more details about the steps aforementioned.

Benefits

Enhanced security through cryptographic signatures
Improved user experience with one-click authentication
Seamless integration with Next.js applications
Robust API route protection using JWT tokens

By implementing SIWE with WalletConnect's AppKit, developers can create secure, user-friendly decentralized applications that leverage the power of Web3 authentication.

Setting Up a VPS on DigitalOcean to Build Your Blockchain Nodes

Thomas Cosialls — Tue, 23 Apr 2024 19:10:35 +0000

Hello, fellow enthusiasts! If you're reading this, you're probably as excited about blockchain as I am. Today, we're going to take a significant step in our blockchain validator journey by setting up a Virtual Private Server (VPS) on DigitalOcean. Don't worry if this sounds daunting; I promise to keep things simple and jargon-free!

Why DigitalOcean?

DigitalOcean is one of the leading cloud infrastructure providers, known for its simplicity and cost-effectiveness. For blockchain enthusiasts like us, it offers a reliable platform to experiment, learn, and grow.

The easy way to start your VPS

1. Sign Up & Login

First things first, head over to DigitalOcean's website (you get $200 free credit with this referal link!). If you're new, sign up; otherwise, log in.

2. Create a Droplet

In DigitalOcean lingo, a 'Droplet' is essentially your VPS. Click on the 'Create' button, followed by 'Droplets'. There, you'll be presented with various configuration options.

3. Choose Your Configuration

Choose a data center region closest to you (or closest to your end user) for optimal performance
Select an OS: I prefer Ubuntu with the latest LTS version, 22.04 at the time of writing.
Pick a server size: for our blockchain validator journey, I recommend starting with the Basic plan (Share CPU) with Regular SSD disk. As you grow, you can always scale up.

select vps size digitalocean

4. Attach your SSH Keys to the Droplet

You now need to set up SSH keys to securely access your VPS remotely. Sounds like Chinese to you? Don't get scared here, just click "New SSH keys" and carefully follow the instructions given on the right side of the modal panel. You can read more about how to setup your SSH keys here.

5. Additional Options & Setup

You'll find additional options like backups, monitoring, database or extra volume. I only recommend selecting monitoring (it's free). Finally, create a new project and assign it to your droplet.

6. Launch & Celebrate!

Click the "Create Droplet" button. In a few moments, your VPS will be up and running. Congratulations!

In Conclusion

Setting up a VPS on DigitalOcean is more than just carving out a personal space in the digital realm; it's the foundational step towards building a validator node in the blockchain ecosystem. A validator node is crucial for ensuring the integrity and functionality of a blockchain network.

By starting with a VPS, you're not just dipping your toes into the blockchain waters; you're gearing up to play a pivotal role in the decentralized future. As you embark on this journey, remember that every validator node begins with a reliable and secure server. So, here's to the first of many steps in your blockchain adventure. Until next time, happy building!

Liked this article? Read more similar articles on www.proof2work.com/blog

Deploy Upgradeable Smart Contracts with Foundry and OpenZeppelin

Thomas Cosialls — Thu, 04 Apr 2024 22:44:52 +0000

Today, I am gonna teach you how to deploy an upgradeable ERC20 token to Polygon Mumbai with Foundry and OpenZeppelin 🚀

I will assume you already have your Foundry environment set up and have already written an upgradeable smart contract for your ERC20 token, that we will call MyUpgradeableToken.sol. If you need help with this, you can read my full article about deploying an upgradeable ERC20 token with Foundry.

First, set up your environment to using OpenZeppelin's upgradeable contracts and Foundry extensions.

forge install OpenZeppelin/openzeppelin-foundry-upgrades
forge install OpenZeppelin/openzeppelin-contracts-upgradeable

Then modify the foundry.toml file:

[profile.default]
ffi = true
ast = true
build_info = true
extra_output = ["storageLayout"]

[rpc_endpoints]
mumbai = "https://rpc.ankr.com/polygon_mumbai"

Now, you can create a new file called 01_Deploy.s.sol in the script directory. Don't forget to add your own PRIVATE_KEY variable in the .env file.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.25;

import "forge-std/Script.sol";
import "../src/MyUpgradeableToken.sol";
import {Upgrades} from "openzeppelin-foundry-upgrades/Upgrades.sol";

contract DeployScript is Script {

    function run() external returns (address, address) {
        //we need to declare the sender's private key here to sign the deploy transaction
        uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
        vm.startBroadcast(deployerPrivateKey);

        // Deploy the upgradeable contract
        address _proxyAddress = Upgrades.deployTransparentProxy(
            "MyUpgradeableToken.sol",
            msg.sender,
            abi.encodeCall(MyUpgradeableToken.initialize, (msg.sender))
        );

        // Get the implementation address
        address implementationAddress = Upgrades.getImplementationAddress(
            _proxyAddress
        );

        vm.stopBroadcast();

        return (implementationAddress, _proxyAddress);
    }
}

Finally, you can deploy your smart contract to Polygon Mumbai!

forge script script/01_Deploy.s.sol:DeployScript --sender ${YOUR_PUBLIC_KEY} --rpc-url mumbai --broadcast -vvvv

Happy deployment and stay tuned for more tutorials to build and navigate in web3 ! 🏄‍♂️

How to easily optimize your SEO when hosting your site with Netlify

Thomas Cosialls — Fri, 23 Jul 2021 21:18:07 +0000

I love Netlify for hosting my static sites. It's free, fast and the automatic deployments with the Github integration is a game changing. You still need to pay attention to a few points if you want to get the best out of it, especially from a SEO point of view.

Static websites made with Gatsby, NextJS or Hugo have everything to boost your SEO score and help you get the golden 100 mark on Lighthouse.

Indeed, expect to see your speed performances soar, with insanely low FCP (First Contentful Paint) , LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift) values.

The issue

However, a great Lighthouse score does not necessarily mean a better ranking and visibility on search engines. Especially if you host your site on Netlify. The reason? With its default settings, Netlify makes every page of your site available as a page on your custom domain and as a page in a subdomain inside .netlify.app. And God knows how Google for instance does not like duplicate content!

The Solution

Set _redirects file (important!)

First, you need to tell Netlify to redirect your Netlify subdomain to your custom domain. You have two ways to do that:

Create a static folder in your project root and save inside a _redirects file with the following content, by replacing the site name accordingly.

https://[yoursitename].netlify.app/* https://www.[yoursitename].com/:splat 301!

Install gatsby-plugin-netlify plugin, that will automatically generate the _redirects file for you.

Use `rel:"canonical"` on every page

To prevent duplicates and tell Google which page is the original version, make sure to include the following <link> tag inside the <head></head> of every pages.

<link rel="canonical" href="{{ your-base-url }}{{ page-slug }}">

If you have too many pages on your site, doing it manually can quickly become tedious. I suggest you use Gutenberg to automate this process.

Here you are! Your site won't have duplicate content anymore and you should now stay far away from Google SEO penalties.

Other tips

I would also suggest you to use the following Netlify plugins and npm packages to boost your static sites performances

if you used Gatsby: gatsby-plugin-minify, to minify all output HTML files.
Image Optim (Netlify plugin) to compress all your static images
Inline source (Netlify plugin) to inline some sources and assets
Submit sitemap (Netlify plugin) to automatically push your updated sitemap to major search engines after each new build.

If you have any questions, feel free to reach out to me - I'd be happy to help!

Image as a Link with Contentful and Gatsby JS

Thomas Cosialls — Sat, 08 May 2021 23:40:56 +0000

As rich as the Rich Text functionality of Contentful might be, it doesn't include a simple way to create clickable images, i.e images embedded in a HTML link element. Here is a quick workaround with a Gatsby JS frontent.

Create a custom model in Contentful

We are creating a new custom model called ImageWithLink that contains 3 simple fields:

title
image (type Media)
url (type Short text)

You can then use your ImageWithLink model in any Rich Text contents or as part of another model definition.

Integrate with GatsbyJS

I will only emphasize how to generate the custom image with link element when the ImageWithLink model is provided inside a Rich Text field. You need to make sure your GraphQL requests are working correctly and that you imported all packages/functions needed to process Rich Text elements in Gatsby ;) I chose to use a fluid image in my example.

[BLOCKS.EMBEDDED_ENTRY]: node => {
    const {__typename} = node.data.target
    const target = node.data.target

    return <a href={target.url}><img src={target.image.fluid.src} /></a>
}

I hope this will help some of you !
Best ❤️

Forem: Thomas Cosialls

Expo app : RedirectTo field with Supabase Auth always set to localhost

Ship Your Tauri v2 App Like a Pro: GitHub Actions and Release Automation (Part 2/2)

Table of Contents

GitHub Actions Workflow

Trigger: Tag-Based Releases

Build Matrix

Full Workflow File

Step-by-Step Breakdown

Concurrency

Permissions

Checkout

Node.js + npm

Rust Toolchain

Rust Cache

Frontend Dependencies

Apple Certificate Import (macOS only)

Build and Release

Repository Settings

Workflow Permissions

Adding Secrets

Release Automation Script

What It Does

The Script

How the Script Works

Version Bumping

Cargo.lock Regeneration

Changelog Generation

Safe Pre-flight Checks

The Undo Escape Hatch

npm Script Entry Point

The Full Release Flow

1. Prepare

2. Run the Release Script

3. Review and Push

4. Monitor the Build

5. Review the Draft Release

Verifying Your Release

macOS Verification

Windows Verification

Troubleshooting

"Resource not accessible by integration"

macOS: "No signing identity found"

macOS: Notarization fails with "invalid credentials"

Windows: "relic: command not found"

Windows: Azure Key Vault 403 / access denied

Build succeeds but no artifacts on the release

Slow builds

Conclusion

Quick Reference

Ship Your Tauri v2 App Like a Pro: Code Signing for macOS and Windows (Part 1/2)

Table of Contents

Prerequisites

Project Configuration Baseline

macOS Code Signing

1. Apple Developer Account

2. Create a Developer ID Certificate

3. Find Your Signing Identity

4. Create an Entitlements File

5. Configure tauri.conf.json for macOS

6. Set Up Notarization

7. Export Your Certificate for CI

Windows Code Signing

Why Azure Key Vault?

1. Create an Azure Account

2. Set Up Azure Key Vault

3. Create an App Registration

4. Assign Permissions

5. Install relic

6. Create the relic Configuration

7. Configure tauri.conf.json for Windows

Tauri Updater Signing

1. Generate an Update Signing Keypair

2. Configure the Updater

Summary of Secrets

macOS Signing + Notarization

Windows Signing (Azure Key Vault)

Tauri Updater

Complete tauri.conf.json

What's Next

Use `rel:"canonical"` on every page