Get your extension into Haybarn.
It already builds against the Haybarn engine unchanged. Submit upstream and Haybarn rebuilds it automatically โ or submit to Haybarn's mirror directly. Same descriptor either way.
Submit upstream, or to Haybarn directly
Submit upstream
Open a PR on duckdb/community-extensions.
Once merged, Haybarn's mirror rebuilds it automatically โ one review, both engines.
Submit to Haybarn
Open a PR on haybarn-community-extensions
with the same file. Ships on the next build, no upstream wait โ for Haybarn-specific
variants or extensions upstream hasn't taken.
The descriptor โ identical in either repo
extension:
name: my_extension
description: One-line summary
version: 0.1.0
language: C++
build: cmake
license: MIT
maintainers:
- your-gh-handle
repo:
github: owner/repo
ref: <commit-sha>
Optional fields (excluded_platforms, vcpkg_url, โฆ)
match upstream's schema.
Rebuilt, signed, shipped
Rebuild
Builds against the Haybarn engine on a 12-platform matrix โ Linux (glibc + musl, amd64 + arm64), macOS, Windows, Wasm โ pinned to your commit.
Sign
Each binary is signed with the Haybarn key. Same mechanism as DuckDB, different key.
Ship
Published to the Haybarn community channel alongside each engine release.
Needs a patch? Point Haybarn at a fork
The Haybarn engine carries a small patch stack. For the rare extension that needs a tweak to build against it, add two optional fields โ the upstream descriptor stays untouched. Most extensions never need this.
# Only if upstream code needs a patch to build
# against the Haybarn engine.
repo:
github: owner/repo
ref: <commit-sha>
haybarn_fork: Query-farm-haybarn/your-fork
haybarn_ref: <commit-sha>
See what's already built
Live build status for every community extension on the current engine.
The mirror repo
CI workflows, descriptor schema, and the override fields, documented in the README.
Stuck getting an extension to build?
We help maintainers across the line โ vcpkg conflicts, platform build failures, signing, and the long tail of CI quirks.