Most teams today have adopted infrastructure-as-code in some form, such as Terraform modules, CI pipelines, and Git-based workflows. But even with these practices in place, things still break. A terraform apply might succeed in staging, but the production deploy fails because backend isolation wasn’t correctly configured. Compliance policies, like enforcing encryption on all S3 buckets, might be defined somewhere in a wiki or checked via tflint, but they're not enforced in CI before a deploy. Manual changes made directly in the cloud console slip through unnoticed, introducing drift that surfaces only after a downstream failure. So while you may be “doing IaC,” the truth is that your live infrastructure doesn’t always reflect what’s in Gitand that disconnect is where most teams get burned.

This isn’t just theoretical. In a popular Reddit thread, one engineer summed it up well:
“Using raw GHA gets pretty gnarly for Terraform. It's hard to guarantee only a single apply happens… You need to save your plans somewhere between reviews. And things like RBAC just aren't possible.”

CI tools are not built to handle stateful, policy-aware workflows for infrastructure. You end up stitching together fragile glue code to manage plan artifacts, serialize applies, gate policies, and track who changed what. Most teams either hit a ceiling or spend time maintaining tooling instead of infrastructure.

That’s exactly why Firefly introduced Workflows. It’s a purpose-built layer that sits on top of your existing pipelines,GitHub Actions, GitLab, Jenkins, whatever, and brings automation, policy enforcement, and visibility into every deploy. Whether you're just starting to automate infrastructure or running complex GitOps pipelines, Workflows gives you control over how infrastructure is applied, reviewed, and governed.

As Ned Bellavance put it:

“The key here is flexibility,  using the approach that works best for your team and your preferred tooling.”

Firefly Workflows doesn’t force a new paradigm. It enhances the one you already have, with intelligent automation that understands your IaC, aligns it with your policies, and ensures that what’s running in your cloud actually matches what’s in Git.

What Breaks When You Automate Terraform at Scale

Infrastructure-as-Code tools like Terraform solved a major problem, declaring and provisioning infrastructure as versioned code. But when it comes to operationalizing that code across multiple teams, environments, and regions, most teams hit the same wall.

Once you start running Terraform inside CI pipelines, the surface area for problems grows fast:

  • You can’t easily prevent concurrent edits in shared workspaces.
  • There’s no safe, consistent way to store and review plans between the terraform plan and terraform apply stages, especially when approvals span multiple roles or environments such as staging, dev, or prod.
  • Teams struggle to implement policy checks, cost thresholds, or compliance checks before a change is deployed in production.
  • And post-deployment? You’re usually blind. Most CI/CD logs are ephemeral. There’s no link between what was deployed, who triggered it, and what actually changed in the cloud.

Terraform gives you the control plane for infrastructure, but CI/CD wasn’t built to understand infrastructure state. It treats a terraform apply the same as a Docker build or test run, just another shell command. And that’s the root of the problem.

That’s why we built Firefly Workflows: to sit between your Git-based IaC and your cloud runtime, not to replace your CI/CD or Terraform, but to fill the critical gaps they weren’t designed to handle:

  • Add a pre-deploy policy layer that blocks dangerous, expensive, or non-compliant changes.
  • Provide a visual plan graph so engineers can actually understand what will change before it does.
  • Track post-deployment activity in a structured way, tied back to Git commits, authors, and pipelines.
  • Let teams use their existing toolchains, GitHub Actions, GitLab, and Jenkins, without rewrites or wrappers.

Firefly Workflows was designed from the start to support how modern DevOps and platform teams actually work: distributed teams, complex environments, and the constant pressure to ship faster without compromising security or control.

How Firefly Workflows Integrates Without Lock-In

Firefly Workflows was designed to integrate with your existing infrastructure deployment processes, not force you to change them.

Most teams already run Terraform (or OpenTofu or Terragrunt) in CI/CD, GitHub Actions, GitLab CI, Jenkins, etc. Firefly doesn’t touch your pipelines. You keep your automation. You just add a small step to the report plan and apply the activity to Firefly using fireflyci (CLI or Docker image). That’s it.

This gives you:

  • A full plan graph showing resource relationships and dependencies
  • Cost estimates before applying
  • Policy checks through Firefly Guardrails
  • Pull request comments with plan summaries
  • Post-deploy visibility across all cloud resources touched

And Firefly doesn’t store your state or credentials. It just reads the metadata your pipeline already generates. Secrets stay in your own CI/CD secrets manager (e.g., GitHub OIDC, Vault, environment variables). No new runner setup, no state migration, no wrappers.

If your pipelines are solid, you don’t need to rewrite anything; just extend them.

“Firefly is not trying to build an automation platform that you need to adopt... they simply want to help you develop an automation workflow using your existing toolset.”
 — Ned

Bring Your Own CI/CD

Firefly isn’t trying to become your automation engine. It simply enhances your existing one. As seen in the screenshot below, teams can manage workflows tied to any repository or CI tool, without any lock-in or special runners.

This allows you to keep your GitOps flow intact while adding governance and observability where it matters most.

“Firefly is not trying to build an automation platform that you need to adopt... they simply want to help you develop an automation workflow using your existing toolset.”
— Ned in the Cloud

Prefer Fully-Managed Automation? That’s an Option Too.

If you’d rather not manage runners or write your own pipeline logic, Firefly also supports fully managed Workflows.

You define a workspace in Firefly, connect your Git repo, and Firefly takes care of running terraform plan on PRs and then applying after merge. Everything runs in isolated Firefly-managed runners. You can define Terraform/OpenTofu/Terragrunt version, variables, auth, and project access in one place. This setup is clean and fast, ideal if you don’t want to maintain pipeline code.

Let’s walk through what fully-managed automation looks like in practice. In this example, we’ve configured a workspace in Firefly for the production-aws environment. Firefly is set up to automatically run terraform plan when a pull request is created, and terraform apply after it’s merged,  all without writing CI/CD pipeline code or managing runners.

A developer raised the following pull request: Terraform New Workflow: production-aws #1

Firefly kicked in immediately using its managed runners and posted a rich, contextual PR comment via its GitHub bot:

Firefly kicked in immediately using its managed runners and posted a rich, contextual PR comment via its GitHub bot:

Firefly also evaluates tag coverage. In this example, 100% tag coverage was achieved:

Firefly also evaluates tag coverage. In this example, 100% tag coverage was achieved:

You can see the entire flow, init, plan, apply within the Firefly UI alongside detailed logs, outputs, and violation summaries.

Self-Hosted Runners with Firefly Orchestration

Run Terraform, OpenTofu, or Terragrunt plans and apply them inside your own network for compliance, data residency, or low-latency execution needs.

Deploy Firefly’s lightweight agent within your infrastructure, and Firefly will orchestrate workflows using your self-hosted runner while still providing:

  • Full visibility and detailed run history in the Firefly UI
  • Interactive plan graphs
  • Guardrails and policy enforcement
  • Complete traceability and audit logs

Works With

  • Terraform (Cloud or OSS)
  • OpenTofu (1:1 compatible with Terraform)
  • Terragrunt (multi-stack orchestration)

Whether you use managed runners or self-hosted runners, Firefly applies the same orchestration, drift detection, and governance controls across all Infrastructure-as-Code engines.

Enforce Policies with Firefly Guardrails

Firefly Guardrails runs policy checks on every plan before any change in the infrastructure gets applied. They catch misconfigurations early, directly in PRs or CI, not after the fact.

You can define:

  • Cost rules block plans that exceed thresholds (e.g., >$200/month or 15% increase). Here’s a custom guardrail to block out-of-budget EC2 usage:
Cost rules block plans that exceed thresholds (e.g., >$200/month or 15% increase). Here’s a custom guardrail to block out-of-budget EC2 usage:

You can define a Cost Guardrail that restricts EC2 instance types in non-prod environments. For example, only allow t3a.large instances in staging, or enforce spot instance usage in dev.

  • OPA-based policy rules enforce policies like “all S3 buckets must have encryption” or “no EC2s with public IPs.” Here’s a custom guardrail enforcing encryption on storage buckets:
OPA-based policy rules enforce policies like “all S3 buckets must have encryption” or “no EC2s with public IPs.” Here’s a custom guardrail enforcing encryption on storage buckets:

In this example, Firefly uses a predefined OPA policy (S3_Encryption_check) to catch any S3 bucket that lacks server-side encryption.

  • Resource rules control create/update/delete actions for specific resources (e.g., block deleting RDS in prod). Here’s a custom guardrail to block creation of storage buckets:
Resource rules control create/update/delete actions for specific resources (e.g., block deleting RDS in prod). Here’s a custom guardrail to block creation of storage buckets:
  • Tag rules ensure required tags like Environment or CostCenter are always present. Here’s a custom guardrail to enforce tags:
Tag rules ensure required tags like Environment or CostCenter are always present. Here’s a custom guardrail to enforce tags:

Resources that don’t meet this tagging standard get blocked at the CI/CD level, no more hunting down untagged VMs or buckets after the fact.

These checks run automatically whether you use Firefly’s runners or your own CI pipeline with firefly ci. Violations show up in the Firefly UI, PR comments, and Slack/email. You can optionally allow overrides with audit logging.

For many violations, Firefly suggests a fix using AI, so devs can resolve issues directly in their PR before merging.

Below is the Firefly Guardrails creation wizard view, where you can define policy, cost, resource, or tag guardrails, set violation behavior (e.g., strict block), and define scope across workspaces and repositories.

This clean, structured UI helps your team enforce policies consistently while ensuring developers can fix violations early:

This clean, structured UI helps your team enforce policies consistently while ensuring developers can fix violations early:

See What Actually Got Deployed

Even if your plan passed and applied cleanly, you still need to know what actually made it into the cloud. Firefly Workflows gives you a full post-deployment snapshot:

  • Resource delta: What changed, what was added, deleted, or modified?
  • Tag diffing: See tag drift and auto-fix gaps based on tagging policy.
  • Change attribution: Who triggered the deployment, and from which commit?
  • Runtime context: Map every deployed resource to its Terraform module, file, and line of code.

All of this shows up in a single audit timeline, so you don’t have to jump between CI logs, Terraform state, and the cloud console. It’s GitOps with real cloud visibility.

Unified Visibility Across Environments

Most teams today run Terraform across isolated workspaces, one for dev, one for staging, one for prod. That’s fine operationally, but it creates blind spots. There's often no easy way to see how environments differ, what’s drifted, or where things have been modified manually.

Firefly Workflows connects the dots. It maps infrastructure across all environments, tying deployments, plan diffs, and resource changes back to Git. You get a clear, environment-wide view of what was deployed, when, and by whom, whether it came from CI/CD, the console, or somewhere in between.

This helps you:

  • Spot misaligned changes (e.g., different AMIs in staging vs prod)
  • Detect drift introduced outside your workflows
  • Ensure the same policies are consistently enforced across every stage

Everything’s centralized in a single inventory and dashboard, so you’re not flipping between workspaces or guessing where a change originated.

Real-World Use Cases: How Teams Actually Use Firefly Workflows

Firefly Workflows isn’t just another automation toolit’s what teams are using in production to streamline IaC operations and plug the holes traditional pipelines tend to miss. Here’s how it’s being used today:

  • GitHub Actions + Terraform on AWS
     Teams wire Firefly directly into their existing GitHub Actions pipelines to handle Terraform plan/apply workflows. It runs pre-merge policy checks, cost estimation, and post-apply verification without needing to wrap terraform apply in custom scripts or switch to a new CI/CD platform.

  • Terragrunt-Based Multi-Stack Deployments
     For orgs managing multiple environments and layered modules via Terragrunt, Firefly provides a clear audit trail of what changed where. Every terraform apply across environments is tracked with contextual diffs and linked history at the module level.

  • Credential Hygiene and Scoped Access
     Instead of baking cloud credentials into runners or relying on shared secrets, Firefly pulls credentials securely from your CI’s secret manager (e.g., GitHub Secrets, Vault) and scopes them per workflow. This keeps access clean, auditable, and restricted to just what the pipeline needs.

  • ClickOps Detection and Rollback
     When someone makes a manual change in the AWS consolelike opening up an S3 bucket or tweaking an RDS config,Firefly detects it. These changes show up in the inventory view and are linked to the Git history so teams can revert them or re-align via code.

  • Drift + Policy Guardrails
     Firefly continuously watches for drift, whether it came from an emergency hotfix or a portal-based change, and flags it. If the change violates a policy (like enabling public access on a resource), guardrails can block further updates or alert the right team.

These aren’t theoretical workflows. They reflect how real teams are using Firefly in production to stay in control of their infrastructure, even when things change outside of code.

Try Firefly Workflows in Your Stack

Firefly Workflows is available today in every Firefly workspace. You can try it on your own repo, using your existing CI/CD pipeline no retooling required.

Ready to Transform Your Cloud Management?

Discover the power of Firefly Workflows and how it can revolutionize your cloud operations. Watch Ned in the Cloud give a detailed product demonstration and explain how workflows can help you optimize your Terraform automation.

Ready to see it in action? Schedule a demo now.

‍Already a Firefly customer? Try it now!