Pre-alpha

Type-safe IaC for Dart.

Terraform stays. You author in Dart. Define typed GCP resources and emit standard *.tf.json for the terraform apply pipeline you already run.

GitHub pub.dev Docs

Example

GCP resources in Dart

A Cloud Run service wired to Cloud SQL with its password pulled from Secret Manager — typed helper classes, sealed env-var sources, and enums where the provider documents values. This is not marketing pseudocode: it is an excerpt of a cookbook recipe that CI analyzes on every pull request and applies against a real GCP project.

// cookbook/single-project-app/lib/service.dart (excerpt — real, apply-verified code)
GoogleCloudRunV2Service buildCloudRunService({
  required GoogleServiceAccount runSa,
  required GoogleSqlDatabaseInstance sqlInstance,
  required GoogleSqlDatabase sqlDatabase,
  required GoogleSecretManagerSecret dbPasswordSecret,
}) =>
    GoogleCloudRunV2Service(
      localName: 'coffee_service',
      name: TfArg.literal('coffee-shop'),
      location: TfArg.literal('asia-northeast1'),
      ingress: TfArg.literal(Ingress.all),
      deletionProtection: TfArg.literal(false),
      template: CloudRunV2ServiceTemplate(
        serviceAccount: TfArg.ref(runSa.email),
        containers: [
          CloudRunV2ServiceServiceContainer(
            image: TfArg.literal(
              'us-docker.pkg.dev/cloudrun/container/hello',
            ),
            env: [
              CloudRunV2ServiceEnvVar(
                name: TfArg.literal('DB_INSTANCE'),
                source: CloudRunV2ServiceEnvVarFromLiteral(
                  TfArg.ref(sqlInstance.connectionName),
                ),
              ),
              CloudRunV2ServiceEnvVar(
                name: TfArg.literal('DB_NAME'),
                source: CloudRunV2ServiceEnvVarFromLiteral(
                  TfArg.ref(sqlDatabase.nameRef),
                ),
              ),
              CloudRunV2ServiceEnvVar(
                name: TfArg.literal('DB_USER'),
                source: CloudRunV2ServiceEnvVarFromLiteral(
                  TfArg.literal('coffee_app'),
                ),
              ),
              CloudRunV2ServiceEnvVar(
                name: TfArg.literal('DB_PASSWORD'),
                source: CloudRunV2ServiceEnvVarFromSecret(
                  secret: TfArg.ref(dbPasswordSecret.id),
                  version: TfArg.literal('latest'),
                ),
              ),
            ],
          ),
        ],
      ),
    );

terradart_google ships a curated subset of the HashiCorp google provider — not every resource type yet. The full factory list with runnable examples is on Coverage; complete stacks live in the cookbook and examples on GitHub (both growing).

Why TerraDart

Connect infra and app code with types

A boundary held together by string literals

Topic names in HCL or the console and again in your Cloud Run functions handlers. Renames do not reach subscribers via dart fix. IAM members drift with no compiler visibility. Infra values flowing into app code are often the layer Dart’s type system never sees.

Terraform stays the execution layer

TerraDart is not a parallel runtime. Write Terraform’s resource model as Dart factories and sealed types, then generate *.tf.json for the provider you already use. terraform plan, apply, and remote state stay unchanged.

Dart types where HCL cannot help

Fixed values become enums. Exactly-one-of blocks become sealed classes. Your infra module is a final class … extends Stack — loops, config, and refactors work like any other Dart code.

Read the design rationale →

Compare

Where TerraDart fits

TerraDart fits teams already centered on Dart, already running Terraform (or a compatible pipeline) or managing GCP in the console, where the seam between infra and app code hurts.

	TerraDart	HCL	CDKTF	Pulumi
Dart authoring	Yes	No	No	No
Drop-in for terraform apply	Yes	Yes	Yes	Different model
Curated Dart factories for GCP	Yes	No	No	No
Project status	Pre-alpha	Mature	Archived 2025	Active

HCL has provider schema types; CDKTF bindings are typed in TypeScript and other languages. TerraDart’s difference is Dart-native authoring without replacing your Terraform execution pipeline.

See full comparison →

Pipeline

How it works in three steps

Author in Dart

Subclass Stack with curated google_* factories from terradart_google.

Generate Terraform JSON

stack.writeTo(...) writes *.tf.json — no custom apply runtime.

Apply with Terraform

terraform plan and apply unchanged; state stays where it is.

Details: /docs/architecture · README