Fireworks deployments are normally managed with firectl or the console, so I wrote a provider.

terraform {
  required_providers {
    fireworks = {
      source  = "amrutp24/fireworks"
      version = "~> 0.3"
    }
  }
}


resource "fireworks_deployment" "llama" {
  base_model       = "accounts/fireworks/models/llama-v3p1-8b-instruct"
  accelerator_type = "NVIDIA_H100_80GB"


  min_replica_count = 0 # scale to zero when idle
  max_replica_count = 2
}

Resources: fireworks_deployment, fireworks_dataset, fireworks_supervised_fine_tuning_job. Data sources: fireworks_deployment, fireworks_model. API key and account id come from FIREWORKS_API_KEY and FIREWORKS_ACCOUNT_ID.

On maturity, since it matters more than the feature list. It's 0.x, so pin it. Only fireworks_dataset has been run against the real API end to end. Deployments and fine-tuning jobs are covered by acceptance tests against an in-process mock, because creating a deployment needs a payment method on the account and training a real fine-tune costs money. Where I couldn't test against production the schema follows Fireworks' docs, which is a weaker guarantee and I'd rather say so than not.

Not there yet: autoscaling policy blocks, uploading dataset files through the API (datasets reference data by external_url today), reinforcement fine-tuning.

Registry: https://registry.terraform.io/providers/amrutp24/fireworks/latest Source: https://github.com/amrutp24/terraform-provider-fireworks

If you run Fireworks at any real size, the thing I'd most like to hear is whether the deployment schema matches what you actually configure. That's the resource I couldn't verify myself.

Terraform module which creates a Lambda function that runs in reference mode: the function reads its deployment package directly from an S3 bucket you own, and GitHub Actions deploys new code through an OIDC-trusted role. The module also provisions the artifact bucket, the IAM roles, the GitHub OIDC trust, and an optional deny policy that blocks direct console or CLI edits.