Providers

Fluid Forge uses one contract format across local and provider-backed execution targets.

Why it matters Target a new cloud by changing one line — no per-cloud rewrite, no lock-in at the contract layer. Swap binding.platform and the same contract recompiles for local (DuckDB), aws, gcp, or snowflake; every provider implements the same interface.

Docs baseline

• CLI release covered by the primary docs: 0.10.0
• Default scaffold (fluid init --quickstart) emits fluidVersion: 0.7.2
• Discovery-based scaffolds (fluid init --discover, fluid forge, fluid product-new) emit fluidVersion: 0.7.5 — the latest bundled schema

Some deep-dive provider pages still preserve older 0.7.1 snippets for backward-compatibility context. Those examples should not be read as “current version” guidance.

Provider overview

Fluid Forge registers four apply-capable cloud providers (plus the local DuckDB target). The full roster reported by fluid providers is aws, datamesh_manager, gcp, local, redshift, snowflake:

ODCS / ODPS are spec exporters, not providers. As of v0.10.0 the open-standards exports (ODCS, ODPS, ODPS-Bitol) are surfaced by fluid exporters — they serialize a contract to a spec and do not deploy infrastructure, so they no longer appear in the fluid providers roster.

The CLI surface today is asymmetric for the two spec exporters — fluid odcs exposes export / import / validate / info, while fluid odps-bitol exposes only export / validate / info. The unified fluid odps command covers both specs and adds an import subcommand for Bitol — see fluid odps and fluid odcs.

Compatibility note: fluid generate-airflow still exists, but the primary docs path is fluid generate schedule --scheduler airflow.

Quick start by provider

GCP

gcloud auth application-default login
gcloud config set project YOUR_PROJECT_ID
fluid apply contract.fluid.yaml --provider gcp --yes

AWS

aws configure
fluid apply contract.fluid.yaml --provider aws --yes

Snowflake

export SNOWFLAKE_ACCOUNT=your_account
export SNOWFLAKE_USER=your_user
fluid apply contract.fluid.yaml --provider snowflake --yes

Local

fluid init my-project --quickstart
cd my-project
fluid apply contract.fluid.yaml --yes

Standards and catalogs

Beyond the cloud and local providers, Fluid Forge round-trips contracts against public data-product standards and publishes them to catalogs.

The full list of spec-export formats is surfaced by fluid exporters. Exporters serialize a contract to a spec and are not cloud providers — for deployment targets see fluid providers.

Standards exchange — fluid odps

The unified fluid odps command dispatches both export and import across the ODPS specs via --spec. The spec exporters themselves are bidirectional at the exporter layer (render + import_contract + validate).

Exporter-specific entry points also remain: fluid odps-bitol for the Bitol layout. New scripts should prefer fluid odps with --spec.

Publishing — catalog registrars

v0.8.3 consolidated catalog publishing under one registry. Contracts opt in via properties.catalog.register: [<name>]; three publish-side registrars are active:

The previously-shipped glue and snowflake_horizon registrars were retired in v0.8.3 and folded into the IaC layer — catalog metadata for those targets is now emitted as aws_glue_catalog_table / snowflake_table resources via fluid generate iac. One source of truth, drift-detected by tofu plan.

Notes

• Use provider-specific guides when you need deep target details.
• Use CLI Reference for command syntax.
• Use Getting Started for the local-first workflow.

Need a hand with a specific provider? Start a discussion or open an issue.