# Release Notes Documentation – TypeScript ## Included Files 1. release-notes/2025-10-24.mdx 2. release-notes/2025-11-01.mdx 3. release-notes/2025-11-07.mdx 4. release-notes/index.mdx 5. release-notes/upcoming.mdx ## October 24, 2025 Source: release-notes/2025-10-24.mdx Release notes for October 24, 2025 # October 24, 2025 * **New:** `moose migrate --clickhouse-url` enables serverless ClickHouse schema deploys * **Improved:** `ClickHouseJson` type enables dynamic JSON payloads with fine-grained controls ## Serverless ClickHouse migrations with `moose migrate` Run schema diffs and applies straight against a ClickHouse endpoint—perfect for OLAP-only or CI/CD environments that don’t boot the full Moose runtime. ```bash # Detect changes and persist the migration plan moose generate migration \ --clickhouse-url "https://user:pass@ch.serverless.dev/main" \ --save # Apply the plan directly to ClickHouse moose migrate --clickhouse-url "https://user:pass@ch.serverless.dev/main" ``` 🐙 PR: ([#2872](https://github.com/514-labs/moosestack/pull/2872)) | 📘 Docs: [Serverless ClickHouse migrations guide](/moose/migrate#serverless-deployments) ## Adaptive JSON columns with `ClickHouseJson` Model semi-structured payloads while locking in typed paths for the fields you care about. ```typescript interface UserMetadata { userId: string; sessionId: string; } export interface UserActivity { id: Key; // ClickHouseJson metadata: UserMetadata & ClickHouseJson<256, 16, ["internal.debug"], ["^tmp\\."]>; } ``` 🐙 PR:([#2887](https://github.com/514-labs/moosestack/pull/2887)) | 📘 Docs: [Data modeling](/moose/data-modeling) ## Moose - **`moose migrate --clickhouse-url`** – Generate and apply migrations directly against hosted ClickHouse, ideal for OLAP-only or CI/CD workflows that run without the full Moose runtime. [Docs: Serverless ClickHouse migrations](/moose/migrate#serverless-deployments) | PRs [#2872](https://github.com/514-labs/moosestack/pull/2872). - **LLM-friendly docs & endpoints** – Framework pages expose TS/Py "LLM view" links and the CLI now serves `/llm-ts.txt` + `/llm-py.txt` for assistants that need scoped context. [Docs: LLM docs](/moose/llm-docs) | PRs [#2892](https://github.com/514-labs/moosestack/pull/2892). - **Flexible JSON columns** – `ClickHouseJson` lets models cap dynamic paths, pin typed paths, or skip keys/regexes so ingestion can accept evolving payloads without breaking typed reads. [Docs: Data modeling](/moose/data-modeling) | PRs [#2887](https://github.com/514-labs/moosestack/pull/2887). - **Configurable `source_dir`** – `moose.config.toml` can point at `src/` (or any folder) instead of the default `app/`, simplifying adoption inside existing repos. [Docs: Configuration](/moose/configuration) | PRs [#2886](https://github.com/514-labs/moosestack/pull/2886). - **Array transforms can fan out events** – Transform functions that return arrays automatically emit one Kafka message per element, covering explode/normalize patterns without extra producers. [Docs: Transform functions](/moose/streaming/transform-functions) | PRs [#2882](https://github.com/514-labs/moosestack/pull/2882). - **ClickHouse modeling controls** – Table DSL now covers TTL per table/column, `sampleByExpression`, and fully configurable secondary indexes (type, args, granularity) so you can encode retention + performance plans directly in code. [Docs: TTL](/moose/olap/ttl) • [Docs: Schema optimization](/moose/olap/schema-optimization) • [Docs: Secondary indexes](/moose/olap/indexes) | PRs [#2845](https://github.com/514-labs/moosestack/pull/2845), [#2867](https://github.com/514-labs/moosestack/pull/2867), [#2869](https://github.com/514-labs/moosestack/pull/2869). - **`get_source` MCP tool** – AI assistants can resolve a Moose component (tables, APIs, streams) back to its source file for faster code navigation. [Docs: MCP get_source tool](/moose/mcp-dev-server#get_source) | PRs [#2848](https://github.com/514-labs/moosestack/pull/2848). - **Google Analytics v4 connector** – Service-account authenticated connector streams GA4 reports and realtime metrics into Moose pipelines so marketing data lands without bespoke ETL. [Docs: Connector reference](https://registry.514.ai/connectors/google-analytics) | PRs [registry#121](https://github.com/514-labs/registry/pull/121). - **Connector registry APIs** – Public REST endpoints expose connector metadata, docs, schemas, and versions for catalogs or automation. [Docs: Registry API docs](https://registry.514.ai/docs/api) | PRs [registry#120](https://github.com/514-labs/registry/pull/120). - **Onboarding & docs polish** – Quickstart, auth, materialized view, and config guides now call out install checkpoints, nullable column behavior, and when to prefer `moose.config.toml` over Docker overrides. [Docs: Quickstart](/moose/getting-started/quickstart) | PRs [#2903](https://github.com/514-labs/moosestack/pull/2903), [#2894](https://github.com/514-labs/moosestack/pull/2894), [#2893](https://github.com/514-labs/moosestack/pull/2893), [#2890](https://github.com/514-labs/moosestack/pull/2890). - **Integer validation parity** – The ingest API enforces every ClickHouse integer range (Int8–UInt256) with clear errors, preventing silent overflows. [Docs: Ingest API](/moose/apis/ingest-api) | PRs [#2861](https://github.com/514-labs/moosestack/pull/2861). - **MCP watcher stability** – The MCP server now waits for file-system changes to settle before responding so IDE bots always read consistent artifacts. [Docs: MCP server](/moose/mcp-dev-server) | PRs [#2884](https://github.com/514-labs/moosestack/pull/2884). - **Release + schema compiler hardening** – Version detection ignores CI-only tags, and ClickHouse parsing handles ORDER BY around `PARTITION BY`, `TTL`, `SAMPLE BY`, and secondary indexes even when optional arguments are omitted. PRs [#2902](https://github.com/514-labs/moosestack/pull/2902), [#2898](https://github.com/514-labs/moosestack/pull/2898), [#2897](https://github.com/514-labs/moosestack/pull/2897), [#2889](https://github.com/514-labs/moosestack/pull/2889). - **Proxy request fidelity** – Consumption APIs now preserve headers/body metadata end-to-end, keeping auth tokens and content negotiation intact. PRs [#2881](https://github.com/514-labs/moosestack/pull/2881). ## Boreal - **Navigation slug fix** – Visiting a 404 no longer strips the org ID from subsequent links, so multi-tenant operators stay on the right workspace. ([commercial#1014](https://github.com/514-labs/commercial/pull/1014)) --- ## November 1, 2025 Source: release-notes/2025-11-01.mdx Release notes for November 1, 2025 # November 1, 2025 - **New:** Support for ClickHouse table engines: - [Buffer table engine](/moose/olap/model-table#in-memory-buffer-buffer): smooth ingest spikes before data lands in MergeTree ([ClickHouse docs](https://clickhouse.com/docs/en/engines/table-engines/special/buffer)) - [S3 table engine](/moose/olap/model-table#direct-s3-access-s3): keep data in S3 while ClickHouse reads and writes it on demand ([ClickHouse docs](https://clickhouse.com/docs/en/engines/table-engines/integrations/s3)) - Beta (self-hosted only): [Distributed table engine](/moose/olap/model-table#distributed-tables-distributed): serve cluster-wide queries through Moose-managed tables ([ClickHouse docs](https://clickhouse.com/docs/en/engines/table-engines/special/distributed)) - **Improved:** Serverless migrations gain Redis-backed state storage plus per-table databases. - **Feature that will make a small number of people very happy:** Moose now has a flake.nix to let users install the cli via nix run github:514-labs/moosestack (also provides a dev shell to make contributing easier!) ## Buffer tables for burst protection You can now model ClickHouse Buffer engines in MooseOLAP TypeScript and Python projects. ```ts filename="bufferTable.ts" copy interface PaymentEvent { eventId: Key; amount: number; capturedAt: Date; } ); ``` PR: [#2908](https://github.com/514-labs/moosestack/pull/2908) | Docs: [Buffer engine](/moose/olap/model-table#in-memory-buffer-buffer) • [ClickHouse Buffer engine docs](https://clickhouse.com/docs/en/engines/table-engines/special/buffer) ## S3 tables for object storage You can now model ClickHouse S3 engines in MooseOLAP TypeScript and Python projects. The CLI serializes engine settings, resolves runtime credentials, and enforces the S3 rule set (`PARTITION BY` allowed, `ORDER BY` rejected) so you can read or write datasets that live entirely in S3. ```ts filename="s3Archive.ts" copy interface ArchivedOrder { orderId: string; status: string; processedAt: Date; } ); ``` PR: [#2908](https://github.com/514-labs/moosestack/pull/2908) | Docs: [S3 engine](/moose/olap/model-table#direct-s3-access-s3) • [ClickHouse S3 docs](https://clickhouse.com/docs/en/engines/table-engines/integrations/s3) ## Distributed tables for cluster fan-out Beta (self-hosted only): Not supported on Boreal or ClickHouse Cloud. You can now model ClickHouse Distributed engines in MooseOLAP TypeScript and Python projects. Plans capture the cluster, target database/table, and optional sharding key, while validation checks that the referenced local tables exist on every node before executing migrations. ```ts filename="distributedEvents.ts" copy interface UserEvent { userId: Key; eventType: string; occurredAt: Date; } ); ``` PR: [#2908](https://github.com/514-labs/moosestack/pull/2908) | Docs: [Distributed engine](/moose/olap/model-table#distributed-tables-distributed) • [ClickHouse Distributed docs](https://clickhouse.com/docs/en/engines/table-engines/special/distributed) ## Redis state storage for serverless migrations `moose generate migration` and `moose migrate` accept a Redis URL (flag or `MOOSE_REDIS_CONFIG__URL`) whenever `state_config.storage = "redis"`. The CLI resolves ClickHouse + Redis endpoints, acquires migration locks in Redis, and reuses the same builder across serverless tooling. ```bash filename="Terminal" copy export MOOSE_CLICKHOUSE_CONFIG__URL="https://user:pass@ch.serverless.dev/main" export MOOSE_REDIS_CONFIG__URL="redis://redis.example.com:6379" moose migrate --clickhouse-url "$MOOSE_CLICKHOUSE_CONFIG__URL" --redis-url "$MOOSE_REDIS_CONFIG__URL" ``` PR: [#2907](https://github.com/514-labs/moosestack/pull/2907) | Docs: [Redis state storage](/moose/migrate#state-storage-options) ## Multi-database tables Tables now carry a `database` field through the CLI, codegen, and infrastructure map. Moose will create any `additional_databases`, validate plans that attempt to move an existing table, and surface fully qualified names in `moose ls`. ```ts filename="auditLogs.ts" copy interface AuditLog { id: Key; recordedAt: Date; message: string; } ); ``` PR: [#2876](https://github.com/514-labs/moosestack/pull/2876) | Docs: [Multi-database setup](/moose/olap/model-table#multi-database-setup) ## Moose - **Buffer tables** – Burst-friendly Buffer engines ship with typed config, CLI validation, and template coverage. Docs: [Buffer engine](/moose/olap/model-table#in-memory-buffer-buffer) • [ClickHouse Buffer docs](https://clickhouse.com/docs/en/engines/table-engines/special/buffer) | PR [#2908](https://github.com/514-labs/moosestack/pull/2908) - **S3 tables** – Direct object storage workflows stay in code with S3 engine support and credential handling. Docs: [S3 engine](/moose/olap/model-table#direct-s3-access-s3) • [ClickHouse S3 docs](https://clickhouse.com/docs/en/engines/table-engines/integrations/s3) | PR [#2908](https://github.com/514-labs/moosestack/pull/2908) - **Distributed tables** – Cluster fan-out models emit the correct ClickHouse DDL and guard against missing local tables. Docs: [Distributed engine](/moose/olap/model-table#distributed-tables-distributed) • [ClickHouse Distributed docs](https://clickhouse.com/docs/en/engines/table-engines/special/distributed) | PR [#2908](https://github.com/514-labs/moosestack/pull/2908) - **Serverless migrations stay coordinated** – Redis-backed locks and state storage plug into the existing `moose migrate` flow with env-var overrides for CI/CD. Docs: [Redis state storage](/moose/migrate#state-storage-options) | PR [#2907](https://github.com/514-labs/moosestack/pull/2907) - **Per-table databases** – The migration planner now respects `database` overrides, auto-creates configured databases, and blocks accidental moves between them. Docs: [Multi-database setup](/moose/olap/model-table#multi-database-setup) | PR [#2876](https://github.com/514-labs/moosestack/pull/2876) - **Runtime S3Queue credentials** – Environment variable markers resolve at deploy time for S3Queue sources, keeping AWS keys out of source. Docs: [Streaming from S3](/moose/olap/model-table#streaming-from-s3-s3queue) | PR [#2875](https://github.com/514-labs/moosestack/pull/2875) ## Boreal - Blog redesign. - Fixed the redirect loop after deleting an organization so users land back on the create-org screen instead of bouncing between routes. ## Nix development environment `flake.nix` now bootstraps a full MooseStack build environment (`nix develop` drops you into a development shell that will have everything you need to build all the components of moosestack). If you use Nix, let us know! Give it a go if you have nix installed on your machine with: ```bash nix run github:514-labs/moosestack # -- to pass additional arguments to the cli ``` PR: [#2920](https://github.com/514-labs/moosestack/pull/2920) --- ## November 7, 2025 Source: release-notes/2025-11-07.mdx Release notes for November 7, 2025 # November 7, 2025 - **New:** [Environment file support](/moose/configuration#environment-variables--env-files) with proper precedence (.env < .env.dev < .env.local) - **New:** [FixedString(N)](/moose/olap/supported-types) data type support for optimized storage - **New:** [Ignore partition changes](/moose/migrate#managing-ttl-outside-moose) during migrations to prevent unnecessary table recreations - **New:** [Precise numeric types](/moose/olap/supported-types#numeric-types) for Python (Int8, UInt32, Float64, etc.) ## Environment file support Configure your Moose projects using .env files with proper precedence (.env < .env.dev < .env.local). This makes it easier to manage different configurations across environments without hardcoding values. ```bash filename="Terminal" copy # Create .env files in your Moose project root # Base configuration (lowest precedence) echo "MOOSE_HTTP_SERVER_CONFIG__PORT=3000 MOOSE_CLICKHOUSE_CONFIG__HOST=localhost MOOSE_CLICKHOUSE_CONFIG__PORT=9000" > .env # Development-specific overrides echo "MOOSE_HTTP_SERVER_CONFIG__PORT=3001 MOOSE_LOGGER__LEVEL=debug MOOSE_CLICKHOUSE_CONFIG__DB_NAME=myproject_dev" > .env.dev # Local overrides (highest precedence, gitignored) echo "MOOSE_HTTP_SERVER_CONFIG__PORT=3002 MOOSE_CLICKHOUSE_CONFIG__HOST=127.0.0.1 MOOSE_REDIS_CONFIG__URL=redis://localhost:6380" > .env.local # Start development server - automatically loads .env files # Precedence: .env < .env.dev < .env.local moose dev # For production deployment, only .env is loaded moose prod ``` PR: [#2936](https://github.com/514-labs/moosestack/pull/2936) | Docs: [Environment variables](/moose/configuration#environment-variables--env-files) ## FixedString(N) data type support Support for FixedString(N) data type in data models, allowing you to define fixed-length string columns for optimized storage of data like hashes, IP addresses, and MAC addresses. ```typescript filename="datamodels/NetworkEvent.ts" copy export interface NetworkEvent { id: string; timestamp: Date; // Fixed-length string for MD5 hash (32 hex chars = 16 bytes) md5_hash: string & FixedString<16>; // Fixed-length string for IPv6 address (16 bytes) ipv6_address: string & FixedString<16>; // Fixed-length string for MAC address (17 chars: XX:XX:XX:XX:XX:XX) mac_address: string & FixedString<17>; // Array of MAC addresses for network devices connected_devices: (string & FixedString<17>)[]; // Regular string for variable-length data user_agent: string; // Other fields bytes_transferred: number; is_encrypted: boolean; } ``` PR: [#2939](https://github.com/514-labs/moosestack/pull/2939) | Docs: [FixedString type](/moose/olap/supported-types) • [ClickHouse FixedString](https://clickhouse.com/docs/en/sql-reference/data-types/fixedstring) ## Ignore partition changes during migrations Configure the migration system to ignore PARTITION BY changes when comparing database schemas. This prevents unnecessary table recreations when partition changes are intentionally ignored. ```toml filename="moose.config.toml" copy [migration_config] ignore_operations = ["ModifyPartitionBy"] ``` PR: [#2928](https://github.com/514-labs/moosestack/pull/2928) | Docs: [Ignoring operations](/moose/migrate#managing-ttl-outside-moose) ## Precise numeric types for Python New type aliases for ClickHouse numeric types in Python: Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Float32, and Float64. These provide better type safety and clearer intent when defining data models. ```python filename="datamodels/UserActivity.py" copy from moose_lib import ( Key, IngestPipeline, IngestPipelineConfig, Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Float32, Float64 ) from pydantic import BaseModel from datetime import datetime from typing import Optional class UserActivity(BaseModel): user_id: Key[UInt64] # User IDs are always positive, use UInt64 for large scale event_time: datetime page_views: UInt32 # Daily page views (0 to 4 billion) session_duration: UInt16 # Session length in seconds (0 to 65K seconds) score_delta: Int32 # Score changes can be positive or negative latitude: Float64 # GPS coordinates need high precision longitude: Float64 # GPS coordinates need high precision confidence: Float32 # ML confidence scores (lower precision acceptable) ``` PR: [#2945](https://github.com/514-labs/moosestack/pull/2945) | Docs: [Numeric types](/moose/olap/supported-types#numeric-types) ## Other MooseStack Features and Improvements - **Real-time Docker logs** – Build commands now stream progress in real-time for better debugging. PR [#2958](https://github.com/514-labs/moosestack/pull/2958) - **ClickHouse cluster configuration** – Define clusters for ON CLUSTER operations in distributed environments. PR [#2931](https://github.com/514-labs/moosestack/pull/2931) - **TypeScript MCP template** – Create AI assistants that can query your ClickHouse data via Model Context Protocol. Docs: [MCP template](/moose/templates-examples#typescript-mcp) | PR [#2953](https://github.com/514-labs/moosestack/pull/2953) - **BYOF documentation** – Integration guides for Express, Fastify, Koa, and FastAPI with MooseStack. Docs: [BYOF guide](/moose/app-api-frameworks) | PR [#2935](https://github.com/514-labs/moosestack/pull/2935) ## MooseStack Bug Fixes - **Bug fixes**: (db-pull defaults) [#2956](https://github.com/514-labs/moosestack/pull/2956), (FastAPI OpenAPI paths) [#2957](https://github.com/514-labs/moosestack/pull/2957), (custom database names) [#2955](https://github.com/514-labs/moosestack/pull/2955), (table diffing compatibility) [#2918](https://github.com/514-labs/moosestack/pull/2918) ## Other Boreal Features and Improvements - Added Nix syntax highlighting support for code blocks in the dashboard - Added branch delete button in branch settings with improved loading states ## Boreal Bug Fixes - **Bug fixes**: (Google Tag Manager) [#2940](https://github.com/514-labs/moosestack/pull/2940), (CORS issues) [#2941](https://github.com/514-labs/moosestack/pull/2941) --- ## Release Notes Source: release-notes/index.mdx Moose / Sloan / Boreal Release Notes # Release Notes Welcome to the Moose, Sloan, and Boreal release notes. Here you'll find information about new features, improvements, and bug fixes for all our products. ## Latest Updates * [November 7, 2025](/release-notes/2025-11-07) * [November 1, 2025](/release-notes/2025-11-01) * [October 24, 2025](/release-notes/2025-10-24) ## Installation To get the latest versions of Moose and Sloan: ```bash bash -i <(curl -fsSL https://fiveonefour.com/install.sh) moose,sloan ``` ## Products Our release notes cover updates across three main products: **Moose** - Build analytical backends with code-first infrastructure, including OLAP tables, streaming pipelines, and APIs. **Sloan** - AI-powered MCP tools for automated data engineering and project setup. **Boreal** - Our hosting platform for deploying and managing Moose applications. Select a date from the sidebar to view detailed release notes for that period. --- ## upcoming Source: release-notes/upcoming.mdx ### Highlights * **Moose and Sloan users** can now embed metadata into their Moose primitives, for use by users, their agents, and their metadata tools. * **Sloan users** can read and write from **Databricks** (more coming here soon). ### Sloan MCP #### [Experimental] Wrangler Agent—Databricks tools. We've had a bunch of our users (especially in the enterprise) request deeper integration with Databricks. We've created MCP tooling to allow you to read from Databricks, and create new derivative Databricks managed tables. Turn it on with `sloan config tools`, and adding `experimental-databricks-tools`. [Docs](https://docs.fiveonefour.com/sloan/tool-reference). To connect with your Databricks instance, you'll need to modify the relevant `MCP.json` file to add: ```JSON "DATABRICKS_HOST": "[-].databricks.com", "DATABRICKS_PATH": "/sql/1.0/warehouses/[-]", "DATABRICKS_TOKEN": "[-]", ``` **This allows you to:** * Read from Databricks tables * Create queries and run them against Databricks tables * Create new Databricks managed tables **Future of the feature:** * **Workflows V2**: We're working on bringing schemas into our workflow creation tools, our Databricks integration will be able to leverage these in interacting with Databricks. * **DatabricksTable**: We're working on a new primitive that will allow you to create a Databricks table from a Moose primitive. # Moose + Sloan #### Descriptions in your Moose primitives **Store context about why you are building what you are building, for you and your agents.** Moose primitives can now include descriptions. ```ts const acPipeline = new IngestPipeline( "AircraftTrackingProcessed", { table: true, stream: true, ingest: false, }, { description: "Pipeline for ingesting raw aircraft data" } // new description field! ); ``` **Where is this used?** Sloan tools that create Moose primitives will now write the intention of the Moose primitive into the description field to give tools/agents that work with that primitive in the future more context. Practically, every description is now served to the tools as context too when the infra map is loaded up as context. **Future of the feature:** Two main extensions of this feature are planned: * Embedding the descriptions into the underlying infrastructure (e.g. as table level comments in ClickHouse) * Extending the metadata: * To be on a field level as well as a primitive level * To include any arbitrary key value pair, not just a description (use this for managing labels like PII!)