@@ -22,6 +22,17 @@ This file provides guidance to coding agents when working with code in this repo
   `Copy Function "parquet" is not in the catalog`. Separately, loading an extension
   config no longer links it into the shell/`unittest`: `extension_config.cmake` asks for that with
   `duckdb_extension_statically_link(otlp)`.
+- **Built-in runtime extensions (`DUCKDB_OTLP_BUILT_IN_EXTENSIONS`).** A CMake list of extensions
+  linked into DuckDB instead of `INSTALL`ed by the daemon at startup. `extension_config.cmake`
+  takes each from DuckDB's own pinned config (`duckdb/.github/config/extensions/<name>.cmake`,
+  the commit and patches DuckDB builds against this source), so its ABI matches by construction.
+  `make server-release` (Docker, both daemon CI jobs) sets `DAEMON_BUILT_IN_EXTENSIONS ?= ducklake`
+  and first builds CRoaring, ducklake's one dependency, into `build/deps/croaring`, because the
+  daemon builds run without vcpkg (v4.7.2, not vcpkg's 4.4.2, whose package config CMake 4
+  rejects). The extension distribution builds leave the list empty. `quack` is deliberately not
+  in it: on DuckDB 2.0 it draws tokens from the writable crypto module only httpfs (OpenSSL)
+  provides, so building it in means building httpfs in, against the runtime image's no-libssl
+  design. Linked extensions load in every command, not only `serve`.
 - **Windows (`windows_amd64`, MSVC) builds the extension only.** `CMakeLists.txt` gates the
   native daemon (`duckdb_otlp_server`) and the C++ harnesses (`otlp_seal_harness`,
   `otlp_arrow_harness`) on `NOT WIN32`, because `make release` builds the default ALL target
@@ -89,7 +100,7 @@ CI in `.github/workflows/MainDistributionPipeline.yml`: `daemon-compile` is a ch
 
 On a `v*` tag, `daemon-release` attaches those four binaries to the GitHub release as `duckdb-otlp-<tag>-<platform>.tar.gz` plus `SHA256SUMS`. It recompiles nothing (it downloads the artifacts the build jobs uploaded) and gates on `docker-smoke`, so a binary that failed the e2e never reaches a release. The Darwin artifacts are deliberately named `duckdb-otlp-darwin-*` rather than `duckdb-otlp-server-*`: the latter is the glob `docker-image` downloads, which must only match the Linux binaries. `daemon-release` creates the release when the tag was pushed without one, which in turn triggers `pages.yml` to attach the extension repository.
 
-Extension offline-cache coupling: the `deps` stage pre-`INSTALL`s ducklake/iceberg/httpfs/aws/postgres/quack and community gcs with a throwaway DuckDB CLI into `HOME=/duckdb-home` (copied into the final image, owned by the nonroot user; the CLI itself is not copied). The daemon reuses that cache only because it runs with the same `HOME` and is pinned to the same `DUCKDB_VERSION`. If those diverge, the daemon's startup `INSTALL`/`LOAD` re-downloads (or fails when offline). The `otlp` extension is statically embedded in the daemon and is intentionally not installed. Bind-mounted `/data` must be writable by uid 65532; named/anonymous volumes inherit the image's nonroot ownership automatically.
+Extension offline-cache coupling: the `deps` stage pre-`INSTALL`s iceberg/httpfs/aws/postgres/quack and community gcs with a throwaway DuckDB CLI into `HOME=/duckdb-home` (copied into the final image, owned by the nonroot user; the CLI itself is not copied). The daemon reuses that cache only because it runs with the same `HOME` and is pinned to the same `DUCKDB_VERSION`. If those diverge, the daemon's startup `INSTALL`/`LOAD` re-downloads (or fails when offline). The `otlp` extension is statically embedded in the daemon and is intentionally not installed, and so is `ducklake` (see *Built-in runtime extensions* below), which is what lets the default `local-ducklake` mode run on a DuckDB build that has no published extensions — a 2.0 development build, for one. Bind-mounted `/data` must be writable by uid 65532; named/anonymous volumes inherit the image's nonroot ownership automatically.
 
 ### Building for WebAssembly
 ```bash
@@ -290,7 +301,7 @@ Prefer one canonical page per topic and link to it instead of duplicating exampl
   - **Standard OTLP env vars**: `OTEL_EXPORTER_OTLP_PROTOCOL` (only when no port is explicit), and `OTEL_EXPORTER_OTLP_HEADERS` (`Authorization=Bearer`) are honored. `OTEL_EXPORTER_OTLP_ENDPOINT` is deliberately **not read** (it usually points at the user's real collector, so reading it as a bind address is a footgun); the per-signal endpoint and TLS variables are **rejected at startup** rather than ignored, because silently dropping them would misrepresent the deployment.
   - **AWS credentials use a multi-source chain**: `BuildCredentialChainSecret` emits `CHAIN 'env;config;instance'` when no `AWS_PROFILE` is set (and `CHAIN config` + `PROFILE` when one is). A single-source chain is a trap in both directions — `CHAIN env` cannot see an EC2/ECS instance role, `CHAIN instance` cannot see the standard AWS variables — and this mode set has been bitten by each: `aws-ducklake` hardcoded `CHAIN instance`, and consolidating it onto the shared builder briefly swapped that for `CHAIN env`, taking instance-role credentials away from exactly the deployments that have nothing else. `AwsCredentialsSource` must keep naming the sources the chain actually contains; it previously claimed "environment, then instance role" while the SQL said `env`.
   - **`parquet` locality is `IsRemotePath`, not `IsS3Path`**: `IsS3Path` answers "does this need the S3 credential set", which is a different question from "is this a local directory". Using it as the locality test sent a `gcss://` export path down the local branch — no filesystem extension loaded, empty setup SQL, `validate` reporting success — and the first seal was the first sign. A remote non-S3 path is now recorded as unusable at configuration time. The R2 modes' default DuckLake `DATA_PATH` keeps its trailing slash (`ObjectStorePath` + `"/"`), because DuckLake treats it as a directory prefix and dropping it would repoint an existing deployment at a different prefix than the one in its catalog.
-  - **A mode declares its extensions once**: `ServerConfig::mode_extensions` is a list of `{name, ExtensionSource}` (`BUILT_IN` / `CORE` / `COMMUNITY`), and both the `INSTALL`/`LOAD` prelude (`ExtensionSetupSql`, spliced ahead of each mode's SQL) and the startup banner are derived from it. Each mode used to state the same list twice — once as strings for the banner, once as hand-typed SQL — so they could disagree with no symptom beyond a misleading banner. Provenance is the only thing that varies and it decides everything: `BUILT_IN` (otlp, statically embedded) emits nothing, so an `INSTALL otlp` that would fetch a *different* published build is unrepresentable; `COMMUNITY` emits `FROM community`, without which the install resolves nowhere. `test_generated_sql_installs_exactly_what_the_banner_reports` pins the two renderings together per mode. The image's offline extension cache (`docker/duckdb-otlp-server/Dockerfile`) is a third copy that cannot share the declaration — different language, and `deps` must not depend on `builder` — so `test_the_image_primes_every_extension_some_mode_needs` asserts it covers the union instead; without it, a mode gaining an extension silently sends the container to the network at startup, or fails outright when offline. Quack is declared the same way but kept out of `mode_extensions`, because it is loaded by the serve path only and `query`/`export` must not pull a server extension in: `QUACK_EXTENSION` is declared once and consumed by `StartQuackSql` and by `AllExtensions()` (what the banner prints). It is `CORE` — `INSTALL quack FROM community` 404s while a bare `INSTALL quack` resolves, which is also how the image primes it. Its `LOAD` previously carried no `INSTALL`, so `--quack` failed with `Extension "quack" not found. Install it first` on every host except the container, whose image primes the cache.
+  - **A mode declares its extensions once**: `ServerConfig::mode_extensions` is a list of `{name, ExtensionSource}` (`BUILT_IN` / `CORE` / `COMMUNITY`), and both the `INSTALL`/`LOAD` prelude (`ExtensionSetupSql`, spliced ahead of each mode's SQL) and the startup banner are derived from it. Each mode used to state the same list twice — once as strings for the banner, once as hand-typed SQL — so they could disagree with no symptom beyond a misleading banner. Provenance is the only thing that varies and it decides everything: `BUILT_IN` (otlp, plus any extension the binary links — `Core(name)` asks `LinkedExtensionRegistry` at runtime rather than a build flag, so the answer cannot drift from the link line) emits nothing, so an `INSTALL otlp` that would fetch a *different* published build is unrepresentable; `COMMUNITY` emits `FROM community`, without which the install resolves nowhere. `test_generated_sql_installs_exactly_what_the_banner_reports` pins the two renderings together per mode. The image's offline extension cache (`docker/duckdb-otlp-server/Dockerfile`) is a third copy that cannot share the declaration — different language, and `deps` must not depend on `builder` — so `test_the_image_primes_every_extension_some_mode_needs` asserts it covers the union instead; without it, a mode gaining an extension silently sends the container to the network at startup, or fails outright when offline. Quack is declared the same way but kept out of `mode_extensions`, because it is loaded by the serve path only and `query`/`export` must not pull a server extension in: `QuackExtension()` is declared once and consumed by `StartQuackSql` and by `AllExtensions()` (what the banner prints); it is a function rather than a constant because the linked-extension registry it consults is filled during static initialization. It is `CORE` — `INSTALL quack FROM community` 404s while a bare `INSTALL quack` resolves, which is also how the image primes it. Its `LOAD` previously carried no `INSTALL`, so `--quack` failed with `Extension "quack" not found. Install it first` on every host except the container, whose image primes the cache.
   - **One name per setting, one error per run**: storage configuration used to spell the same concept differently per mode (five names for an R2 access key, `NEON_PG*` vs `PG*` for the same Postgres catalog, six for a bucket) — about 70 variable names for ~25 concepts. Each mode now reads one canonical name: the cloud's own convention where one exists (`AWS_*`, `PG*` libpq names), `R2_*` for R2, `S3_*` for S3, `DUCKDB_OTLP_*` only for this daemon's own settings. `ConfigProblems` (`server_config.cpp`) accumulates every problem with a mode's configuration — absent values via `Add`, set-but-unusable ones via `Invalid` — and `ConfigureMode` throws once naming all of them, deduplicated by variable. Malformed values are recorded rather than thrown so they do not short-circuit the rest of the pass, which is what made `DUCKLAKE_DATA_PATH=/local/path` report the path on one run and `AWS_REGION` only on the next — configuring `r2-data-catalog` took six runs to satisfy when each error named a single variable. `MODES` is one table of `{name, configure}` so the supported-mode list in the error cannot drift from the set actually handled.
   - **`parquet` mode reads back through views, defined in one place**: the mode has no catalog, so a signal is readable only through a view over `<root>/<table>/**/*.parquet`. `SealParquet` already creates that view after each successful export (it can only be created once files exist, which is why mode setup cannot do it), so serving and reading on one host was already covered. What was broken is narrower than it looks: `ExistingSignalTables` asked `duckdb_tables()` only, so `export` found **zero** signal tables and refused to export data that was sitting there readable — it now unions `duckdb_views()`. `RegisterParquetExportViews` (`commands.cpp`, from `OpenConfiguredDatabase`) covers the remaining gap: a dataset written by another process or host, whose control database has never been sealed into. Both sites build the SELECT from `ParquetDatasetSelect` (`otlp_sql_util.hpp`) so the glob depth and the two load-bearing `read_parquet` options cannot drift — `hive_partitioning=false` because the COPY sets `WRITE_PARTITION_COLUMNS false` (year/month/day live only in the path, and inferring them appends three columns no catalog mode has), `union_by_name=true` so a schema change still reads. Registration is scoped to the signals the caller could read — the resolved `--signal` list for `export`, the signal names appearing in the SQL for `query` — because each probe is a directory listing, and a remote LIST apiece against an `s3://` root. A read-only database cannot hold a view, so that path falls back to session-scoped `TEMP VIEW`s.
   - **`--mode none`**: attaches nothing, installs nothing, sets no catalog — the destination is entirely `--init-sql` plus `--catalog`. Every mode contributes only setup SQL and a catalog name (see `BootSql`), both already expressible that way, but without an opt-out an operator's script was layered on top of an unwanted `local-ducklake` ATTACH. The eight presets are a hand-picked subset of (3 catalog kinds × 2 catalog stores × 4 storage backends); `none` is how an uncovered combination (S3 data files with a Postgres catalog, say) is reached without adding a ninth.
 
@@ -86,9 +86,34 @@ wasm_relink: wasm_link
 
 .PHONY: server-release docker-image docker-image-local docker-image-multiarch
 
-server-release: ${EXTENSION_CONFIG_STEP}
+# Runtime extensions the daemon links instead of INSTALLing at startup (see
+# extension_config.cmake). ducklake is the default mode's catalog. quack is not
+# here: on DuckDB 2.0 it draws its tokens from the writable crypto module httpfs
+# (OpenSSL) provides, so building it in means building httpfs in too.
+DAEMON_BUILT_IN_EXTENSIONS ?= ducklake
+
+# ducklake needs CRoaring. The extension builds take it from vcpkg, but the daemon
+# builds (Docker, macOS CI) run without vcpkg, so build it into a private prefix,
+# for the same architecture as the daemon. v4.7.2 rather than vcpkg's 4.4.2: the
+# 4.4.2 package config declares cmake_minimum_required(2.8), which CMake 4 rejects.
+CROARING_VERSION := v4.7.2
+CROARING_PREFIX := $(PROJ_DIR)build/deps/croaring
+CROARING_ARCH_FLAG := $(if $(OSX_BUILD_ARCH),-DCMAKE_OSX_ARCHITECTURES=$(OSX_BUILD_ARCH),)
+
+$(CROARING_PREFIX)/.built-$(CROARING_VERSION):
+	rm -rf build/deps/croaring-src $(CROARING_PREFIX)
+	git clone --quiet --depth 1 --branch $(CROARING_VERSION) https://github.com/RoaringBitmap/CRoaring build/deps/croaring-src
+	cmake $(GENERATOR) -S build/deps/croaring-src -B build/deps/croaring-build -DCMAKE_BUILD_TYPE=Release \
+		-DCMAKE_INSTALL_PREFIX=$(CROARING_PREFIX) -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DBUILD_SHARED_LIBS=OFF \
+		-DENABLE_ROARING_TESTS=OFF -DROARING_USE_CPM=OFF $(CROARING_ARCH_FLAG)
+	cmake --build build/deps/croaring-build --target install
+	touch $@
+
+server-release: ${EXTENSION_CONFIG_STEP} $(CROARING_PREFIX)/.built-$(CROARING_VERSION)
 	mkdir -p build/release
-	cmake $(GENERATOR) $(BUILD_FLAGS) $(EXT_RELEASE_FLAGS) $(VCPKG_MANIFEST_FLAGS) -DCMAKE_BUILD_TYPE=Release -S $(DUCKDB_SRCDIR) -B build/release
+	cmake $(GENERATOR) $(BUILD_FLAGS) $(EXT_RELEASE_FLAGS) $(VCPKG_MANIFEST_FLAGS) -DCMAKE_BUILD_TYPE=Release \
+		-DDUCKDB_OTLP_BUILT_IN_EXTENSIONS="$(DAEMON_BUILT_IN_EXTENSIONS)" -DCMAKE_PREFIX_PATH=$(CROARING_PREFIX) \
+		-S $(DUCKDB_SRCDIR) -B build/release
 	cmake --build build/release --config Release --target duckdb_otlp_server
 
 docker-image: docker-image-local
 
@@ -70,9 +70,12 @@ RUN set -eux; \
     rm -f /tmp/duckdb.zip
 
 # Prime every mode's extensions into HOME=/duckdb-home so the daemon's startup INSTALL/LOAD
-# is offline. The daemon (otlp) is statically embedded and is intentionally not installed.
+# is offline. Extensions statically linked into the daemon are intentionally not installed:
+# otlp, plus ducklake (`make server-release` builds it from DuckDB's pinned config, so the
+# default local-ducklake mode downloads nothing and does not depend on a published build
+# matching the daemon's DuckDB ABI).
 RUN set -eux; mkdir -p "${HOME}"; \
-    for ext in ducklake iceberg httpfs aws postgres quack; do \
+    for ext in iceberg httpfs aws postgres quack; do \
         /tmp/duckdb-cli/duckdb -unsigned -c "INSTALL ${ext};"; \
     done; \
     /tmp/duckdb-cli/duckdb -c "INSTALL gcs FROM community; LOAD gcs;"; \
 
@@ -16,4 +16,21 @@ endif()
 # when a config asks for it; loading it no longer implies linking it.
 duckdb_extension_statically_link(otlp)
 
+# Runtime extensions compiled into the binary instead of INSTALLed when it
+# starts, e.g. "ducklake;quack" (set by `make server-release`). Each one is
+# taken from DuckDB's own pinned config -- the commit and patches DuckDB builds
+# and tests against this source -- so its ABI matches the daemon by
+# construction, which no published binary can promise for a development build.
+# The daemon notices at runtime that an extension is linked and stops emitting
+# INSTALL/LOAD for it.
+set(DUCKDB_OTLP_BUILT_IN_EXTENSIONS
+    ""
+    CACHE STRING "Extensions to link into DuckDB from DuckDB's pinned configs")
+foreach(built_in IN LISTS DUCKDB_OTLP_BUILT_IN_EXTENSIONS)
+  include(
+    "${CMAKE_CURRENT_LIST_DIR}/duckdb/.github/config/extensions/${built_in}.cmake"
+  )
+  duckdb_extension_statically_link(${built_in})
+endforeach()
+
 # Any extra extensions that should be built e.g.: duckdb_extension_load(json)
@@ -3,6 +3,7 @@
 #include "duckdb/common/error_data.hpp"
 #include "duckdb/common/exception.hpp"
 #include "duckdb/common/string_util.hpp"
+#include "duckdb/main/extension/linked_extension_registry.hpp"
 #include "env_source.hpp"
 #include "otlp_sql_util.hpp"
 #include "otlp_uri.hpp"
@@ -479,9 +480,24 @@ CREATE OR REPLACE SECRET %s (
 	return secret_sql;
 }
 
-//! Shorthands for declaring a mode's extension list.
+//! Whether an extension is compiled into this binary (`DUCKDB_OTLP_BUILT_IN_EXTENSIONS` at build
+//! time). Asked of the binary itself rather than of a build flag, so the answer cannot drift
+//! from what was actually linked.
+bool IsLinkedIntoBinary(const string &name) {
+	for (auto &linked : duckdb::LinkedExtensionRegistry::Get()) {
+		if (StringUtil::CIEquals(linked.name, name)) {
+			return true;
+		}
+	}
+	return false;
+}
+
+//! Shorthands for declaring a mode's extension list. A core extension linked into the binary
+//! is built in: DuckDB loads every linked extension when the database opens, and INSTALLing it
+//! would fetch a published build that is not the one running -- for a DuckDB development build,
+//! one with a different ABI, if it exists at all.
 ModeExtension Core(const char *name) {
-	return {name, ExtensionSource::CORE};
+	return {name, IsLinkedIntoBinary(name) ? ExtensionSource::BUILT_IN : ExtensionSource::CORE};
 }
 
 ModeExtension Community(const char *name) {
@@ -493,8 +509,11 @@ ModeExtension Community(const char *name) {
 //! LOAD, which is why the banner used to omit it even when Quack was running.
 //!
 //! CORE, not COMMUNITY: `INSTALL quack FROM community` 404s, while a bare `INSTALL quack`
-//! resolves from the core repository (which is also how the image primes it).
-const ModeExtension QUACK_EXTENSION = {"quack", ExtensionSource::CORE};
+//! resolves from the core repository. A function, not a constant: whether it is built in is read
+//! from the linked-extension registry, which is filled during static initialization.
+ModeExtension QuackExtension() {
+	return Core("quack");
+}
 
 //! The otlp extension, statically embedded in the daemon. Declared so the banner reports it,
 //! never emitted as SQL -- INSTALLing it would reach for a published build that is not the one
@@ -1331,7 +1350,7 @@ FROM %s(
 std::vector<ModeExtension> ServerConfig::AllExtensions() const {
 	auto extensions = mode_extensions;
 	if (quack_enabled) {
-		extensions.push_back(QUACK_EXTENSION);
+		extensions.push_back(QuackExtension());
 	}
 	return extensions;
 }
@@ -1340,7 +1359,7 @@ string ServerConfig::StartQuackSql() const {
 	if (!quack_enabled) {
 		return "";
 	}
-	return ExtensionSetupSql({QUACK_EXTENSION}) + StringUtil::Format(R"SQL(
+	return ExtensionSetupSql({QuackExtension()}) + StringUtil::Format(R"SQL(
 SELECT listen_uri
 FROM quack_serve(
     %s,