Infrastructure Automation & Self-Service

Use Case: A large enterprise wants to enable development teams to provision cloud infrastructure on their own ("self-service"), but without compromising on standards or creating unmanaged sprawl. Traditionally, every request went through an Ops team and took weeks. With Firefly | Manage Your Cloud with Infrastructure-as-Code, they aim to accelerate infrastructure delivery via automation, while the platform team retains governance.

Developer Self-Service via Compose AI

The platform team exposes Firefly's Compose AI to developers (perhaps through an internal portal or by giving them access with guidance). When a dev team needs a new environment or resource:

• They describe what they need in Compose AI (for example, "3 servers and a database for a new microservice X in staging"). The AI generates the Terraform config.

• The dev team reviews the suggestion, maybe tweaks a few parameters (with AI help or manually).

• They then use Firefly to create a pull request to the infra repository with this new configuration.

• The CI pipeline runs, and because Firefly's Workflows and guardrails are in place, it automatically checks that what they're proposing meets company policies (e.g., all resources have tags, no open security groups, cost within limits).

• Once it passes review (and any approvals), it gets deployed. Firefly now monitors those resources just like any others.

This process can happen in hours instead of days. Best Practice: Establish a self-service workflow where Firefly is the intermediary: Developers request infra by writing code (or using Compose AI), not tickets. Ensure they have training on using Firefly Compose and understanding guardrail feedback. Over time, they will learn company standards by the suggestions and constraints the system provides (e.g., if they request something insecure, the AI might even warn them or the guardrail will block it; they'll adjust accordingly).

Standardized Stacks and Modules

The platform team encodes common patterns as modules (or identifies well-maintained public modules). In Firefly Compose, those are readily available. For instance, "Need a web service with autoscaling" – instead of reinventing, the AI might assemble this from a standard VPC module + ASG module + ALB module the company trusts. This ensures even self-service creations align with best architecture practices.

Best Practice: Maintain an IaC module library and educate the AI about it (if needed by providing it in training prompts or documentation). Firefly can then leverage those modules in Compose suggestions, ensuring consistency. This reduces snowflake designs and makes infrastructure more homogeneous (which is easier to manage).

Infrastructure Pipelines as a Service

Firefly Workflows allows the platform team to set up pipelines once, and developers simply push code to trigger them. For example, the platform team sets up a Jenkins or GitHub Actions pipeline template for Terraform that includes Firefly agent steps and guardrails. Each new project can reuse this pipeline config with minimal changes. This "pipelines as a service" model means dev teams don't have to create their own CI for infra – it's given, integrated with Firefly for checks.

Best Practice: Use Firefly's documentation and examples to create a reference CI pipeline for infrastructure. Include steps: terraform init/plan, Firefly post-plan scan, maybe manual approval if needed, terraform apply, Firefly post-apply. Share this with all teams. This standard pipeline reduces errors (everyone gets guardrails by default) and speeds up onboarding of new projects.

Drift Remediation by Developers

If a dev team's resources drift (maybe someone tweaked something in the console for an urgent fix), Firefly catches it. In the past, the ops team might have to fix it or it might go unnoticed. Now, Firefly notifies the dev team (since they "own" those resources via tags). The developers themselves can use Firefly to recodify the change into their Terraform code or revert it. This pushes responsibility to the teams but in a controlled way – they have the tools to do it safely.

Best Practice: Encourage a culture where developers handle their infrastructure issues as part of "you build it, you run it". Firefly's user-friendly interface (especially with AI help) makes it feasible even if the devs aren't Terraform experts. For example, if a drift says "instance type changed", the dev can ask Compose AI "Update my Terraform for service X to use instance type Y" – it will generate the code change, which they can PR and apply. This reduces backlog on the central ops team and speeds up resolution.

Role and Access Management

With Firefly, even giving broader access to create infra, you maintain a single point of control. The platform team can monitor all changes through Firefly, and because everything goes through code and pipelines, there's an audit trail. No one is going rogue with full cloud admin rights; they operate within the boundaries Firefly sets.

Best Practice: Limit direct cloud access for developers – instead, funnel their actions through Firefly's controlled processes. This means if they need a new IAM role or to open a port, they do it via code (which is reviewed and approved), not by manually clicking in the console. Firefly will catch any out-of-band changes anyway, so over time developers realize it's easier to do it the proper way first.

Results

The enterprise saw deployment times for infrastructure go from ~4 weeks (ticket -> design -> review -> create) down to 2-3 days or even hours for small changes. Developers are happier because they have more control and faster feedback. The platform team is less a gatekeeper and more an enabler, focusing on providing a stable platform and guardrails rather than manually executing every change. And despite decentralizing infra changes, compliance and security are actually stronger because Firefly ensures everything is tracked and vetted.