Skip to main content
Fluid Forge

Fluid Forge

Declare a data product once in a contract. Build it on your laptop, deploy it to AWS, GCP or Snowflake, and verify that what landed matches what you declared.

Get startedTutorialsConceptsCLI reference

Local first

Install with the local extra, then validate, plan, apply, verify and test a product on DuckDB before you touch a cloud credential.

One contract, one file or many

Write a product as one file, or as a root contract plus fragment files. validate, plan and apply resolve the fragments into one document.

Environments and two clouds

--env picks an overlay that patches the base contract. Since 0.17.0 one contract deploys to AWS and to GCP this way, with its retention, encryption and column restrictions mapped to each cloud's own resources.

Verify what landed

fluid verify reads the deployed target and compares it with the contract. With --strict, drift fails the build, so it can gate CI.

Sovereignty enforced

Pin a jurisdiction in the contract and the engine blocks a mismatched binding. An EU contract bound to us-east-1 fails "fluid validate" with exit 1.

Command Center

fluid publish sends a product to a FLUID Command Center catalog, and fluid apply reports its runs there once a credential is configured.

Fluid Forge is a command-line tool, fluid, for data engineers who build data products. You describe a product in a contract: its schema, how it is built, where it lands, its quality rules, who may read it and where it may live. The CLI validates the contract, plans and applies it to the platform the binding names, and checks the deployed result against it.

  • The contract is the source of truth. The plan, the cloud resources, the access rules and the checks fluid verify runs are all derived from it. See What is a contract.
  • One contract, several places. An overlay per environment patches the binding, so the same contract runs in dev and prod, or on AWS and GCP. See Environments and overlays and Governance parity.
  • Checked before and after. fluid validate refuses a contract that breaks the schema or its own sovereignty pin; fluid test runs the data-quality rules; fluid verify compares what landed with what was declared.

Where Forge does and does not fit next to dbt, Terraform, Airflow and Snowpark: Fluid Forge vs alternatives.

Run it

pip install "data-product-forge[local]"
mkdir fluid-quickstart && cd fluid-quickstart
fluid init my-first-product --blueprint fluid.starter
cd my-first-product
fluid validate contract.fluid.yaml
fluid plan contract.fluid.yaml
fluid apply contract.fluid.yaml --yes --mode amend-and-build
fluid verify contract.fluid.yaml --strict
cat runtime/out/my-first-product.csv

message,created_at
Hello from the my-first-product data product,2026-10-05 10:35:49.479853+02

Getting Started walks through each step with its output, then makes the product read a CSV and adds a data-quality rule. It explains why it uses the fluid.starter blueprint rather than fluid init --quickstart on 0.18.1.

This site documents CLI 0.18.1, with contract schema 0.7.5 as the stable default and 0.7.6 as an opt-in preview. fluid version is the CLI release you installed; fluidVersion inside a contract is the schema version it is written against. Which version each scaffold writes is in Understand the version numbers.

Follow one product from laptop to production

The docs are ordered as the life of a data product. Each step links to the page that covers it:

  1. Install and build locally: Getting Started, then the local walkthrough.
  2. Understand the contract: What is a contract, Builds, exposes, bindings, and the contract reference.
  3. Split it into files: Contract fragments and $ref.
  4. Run it in each environment, and on two clouds: Workspaces, Environments and overlays, One contract, two clouds, OpenTofu state.
  5. Govern it: Governance and policy, Governance parity, Sovereignty, Agent policy.
  6. Ship it: The 11-stage pipeline, Declarative Airflow, fluid publish and the Command Center.
  7. Change it and upgrade: Change a live data product and Upgrading.

See it run

A 60-second walkthrough of the core move: one contract.fluid.yaml, built and tested locally on DuckDB, then pointed at BigQuery and Snowflake by changing its binding. In the sovereignty-platform-swap example the AWS, GCP and Snowflake contracts differ only inside binding; run diff on them to check.

Use ←/→ to step scenes, space to pause, r to restart. The reels were recorded on an earlier CLI; See it run has the full set and says what has changed since.

AI-assisted scaffolding

fluid forge
fluid forge --domain retail

fluid init scaffolds from a fixed template or blueprint. fluid forge drafts a contract from the files in your directory with the LLM provider you configure with fluid ai setup. To forge a data model from a business intent file and generate dbt from it:

fluid forge data-model from-intent --example retail > intent.yaml
fluid forge data-model from-intent intent.yaml -o customer_orders.fluid.yaml
fluid generate transformation customer_orders.fluid.yaml -o ./dbt_customer_orders --dbt-validate

See AI forge and data-model journeys.

These are the groups fluid --help prints on 0.18.1:

GroupCommands
Core Workflowinit, forge, validate, plan, apply
Generategenerate transformation, generate schedule, generate ci, generate standard
Integrationspublish, market, import, mcp
Quality & Governancepolicy-check, test
Safety & Supply Chainrollback, verify-signature
Utilitiesconfig, ai, split, auth, doctor, providers, exporters, version

--help promotes a short surface. Commands such as bundle, diff, verify, runs, stats, ship and mission are registered and documented, and --help names the production path as bundle → validate → generate artifacts → diff → plan → apply → verify → publish. The CLI reference covers the commands.

Current release — 0.18.1, schema 0.7.5 stable (GA)

pip install data-product-forge gives you 0.18.1. Its notes: 0.18.0 and 0.18.1. Coming from an older release? The upgrade guide has a checklist for each version you cross.

Since 0.15.0:

  • 0.15.1–0.16.2 (notes) — a stage name such as ../../ESCAPED can no longer make fluid generate transformation write outside --output, and contract values are escaped in generated Airflow, Prefect and Dagster code. Generated SQL now creates views, which drops grants on Snowflake and Databricks. AWS resources go to the binding's region, and BigQuery bindings load their rows.
  • 0.16.3–0.17.0 (notes) — one contract deploys to AWS and to Google Cloud through --env overlays and is governed the same on both, checked by fluid verify. The generated 11-stage pipeline runs as generated. Upgrading has one-time steps: retire old Airflow DAGs, move state to a per-provider key, and let the first GCP apply revoke stale dataset grants.
  • 0.18.0 — a contract's $ref and its SQL are confined to the contract's directory tree and declared locations, unless you widen them.
  • 0.18.1 — the drift gate (fluid diff --exit-on-drift) reads a target whose binding names its project or path through an environment variable.
Before that, each release keeping its own work
  • 0.15.0 — sovereignty enforcement: sovereignty.enforcementMode blocks, warns or informs as declared, the region→jurisdiction table comes from the vendors' data, and a jurisdiction-pinned MCP output port refuses to start on stdio, or on HTTP with no auth mode. It documents 0.14.1 with it.
  • 0.14.0 — live-verification hardening: the dbt Iceberg loop reaching all three cloud warehouses.
  • 0.13.0 — verifiable autonomy and declarative packaging, with the fluid mission command.
  • 0.12.0 — dbt integration and schema GA: 0.7.5 promoted to stable as the default for untagged contracts, plus the brownfield fluid import dbt importer.
  • 0.11.0 — the AI-ready / RAG surface: vector output port, semantic-drift guard, ai_ready agent.
  • 0.10.0 — plugin governance: an operator trust boundary over plugins, with fluid plugins and fluid exporters.
  • 0.9.0 — the streaming Kafka → Iceberg sink.
  • 0.8.6 — the fluid mcp output-port gateway: agentPolicy enforced at runtime, with JWT-bearer identity.

The vocabulary and the product types behind all of it: SDK & Plugins, Source-Aligned Acquisition, Product Types.

Where to go next

Need help?

Apache 2.0 Licensed | Documentation for the Fluid Forge CLI