AI-powered Intent-to-Infrastructure. Turn your intent into production Terraform code and diagrams. Try it free.
Backstage Plugin for Self-Service Infrastructure: Beyond Scaffolding

Backstage has quickly become the standard interface for platform engineering teams aiming to deliver internal developer portals. It promises golden paths, discoverability, and service onboarding in minutes. But when it comes to infrastructure provisioning, the experience often falls short. Most teams are using Backstage as a trigger for GitOps pipelines, but not as a true interface for infrastructure modeling. And despite the proliferation of Infrastructure-as-Code tools like Terraform and Pulumi, 65% of platform teams still rely on tickets to provision resources, according to the 2024 CNCF survey. This disconnect between developer experience and infrastructure complexity creates friction, delays, and an ever-growing backlog for platform engineers.
In this blog, we’ll explore why self-service infrastructure continues to break down in practice and how StackGen’s Infrastructure-from-Code plugin changes that. We’ll walk through what makes current abstractions fragile and what a hands-on integration looks like inside Backstage. Along the way, we’ll highlight use cases, technical benefits, and how platform teams can retain control without becoming bottlenecks.
How StackGen Bridges the Gap Between Developer Intent and Infrastructure Code
Note: System Model sync from StackGen to Backstage is a roadmap feature and not yet implemented.
Design Infrastructure Visually, Without Writing Terraform
Most developers don’t want to write infrastructure code; they want environments that work. With StackGen, developers don’t need to write Terraform manually. The Backstage plugin syncs metadata, such as service name, owner, and tags, from Backstage into StackGen. From there, developers work in StackGen’s topology canvas, where they visually design infrastructure stacks, define resource relationships, and bind parameters. Once the blueprint is ready, StackGen generates Terraform and handles Git-based delivery.
Under the hood, StackGen compiles this blueprint into modular, version-controlled Terraform. Developers don’t touch the code unless they want to. Platform engineers can still review it before deployment, but the source of truth is now the blueprint, not a manually written main.tf.
Build for Any Cloud Without Changing Your Workflow
Choosing a cloud provider shouldn't mean re-learning how to define infrastructure. StackGen supports AWS, Azure, and GCP out of the box. The visual blueprint remains the same regardless of the provider, and StackGen handles the mapping behind the scenes.
For example, a GCP-based blueprint using GKE and Cloud SQL can be automatically converted into an AWS stack using EKS and RDS. This is especially valuable for platform teams supporting multiple business units, regions, or regulatory environments.
Multi-cloud no longer requires maintaining parallel templates or forcing developers to learn multiple cloud platforms. The abstraction remains consistent while the output adapts to the cloud context.
No More Guesswork Around Dependencies and Wiring
Manually wiring resources in Terraform is one of the biggest causes of onboarding friction and broken deployments. Outputs must be passed across modules, resources depend on each other in subtle ways, and misconfigured providers lead to errors that are hard to debug.
StackGen solves this for its built-in modules by modeling each component’s inputs and outputs directly on the Topology canvas. When a frontend app connects to a database, StackGen knows to provision the correct security groups, inject connection strings as environment variables, and create the correct depends_on structure.
For custom modules, StackGen can still generate Terraform, but automation depends on how closely those modules follow StackGen’s expected interface (e.g., defined inputs/outputs, naming patterns, etc.). Some abstractions may require manual metadata or additional mapping.
Here's a simplified example of what StackGen generates for an app connected to a PostgreSQL instance:
Developers don't have to write the above code. They can define relationships through the UI, and StackGen will generate consistent, validated Terraform code automatically.
Production-Ready Code That Fits Into GitOps
StackGen doesn’t invent a new workflow. Instead, it generates Terraform code that is modular, readable, and follows platform conventions. Each blueprint creates a directory with a clean structure, using internal or pre-approved modules. Output is pushed to a Git repo, typically on a feature branch, ready for review.
The integration doesn’t stop at code generation. StackGen can trigger pull requests, add reviewers, and notify GitOps tools like ArgoCD or Atlantis to start the apply process once approved. Teams already using GitOps don’t need to change anything; StackGen simply becomes the starting point for infrastructure-as-code.
This lets platform teams retain full control over the infrastructure lifecycle, while developers gain a much faster and safer way to request what they need.
Infrastructure-from-Code: What It Really Means
From Handcrafted Terraform to Blueprint-Driven Workflows
Writing Terraform is like assembling furniture from parts instead of using a kit. You have to know every screw, joint, and measurement. Infrastructure-as-Code works great if you’re an expert builder, but most developers just want to “set up a room,” not design the beams.
Infrastructure-from-Code flips the model. Developers define what they want, “a web service with a database in production”, and the system takes care of the implementation details. StackGen’s visual canvas acts as the UI layer between developer intent and cloud configuration.
A Visual Starting Point, Not a Blank File
Instead of opening a blank .tf file and wondering where to start, developers drag resources onto a canvas: a containerized service, a database, maybe a load balancer. StackGen knows how these elements connect and generates the correct Terraform for AWS, Azure, or GCP.
Here’s the difference in practice:
Infrastructure-as-Code
You write something like this manually:
Infrastructure-from-Code
You select “PostgreSQL” on the canvas, connect it to your app, and the code above is generated, parameterized, and pushed to Git.
The platform team still controls the modules, policies, and naming conventions, but developers never touch the low-level infrastructure details.
GitOps Remains the Backbone
Even though the experience begins in a UI, StackGen never skips the review process. Once a blueprint is built, the Terraform is pushed to Git as a pull request. CI pipelines, code owners, and GitOps deployment flows (e.g., ArgoCD, Atlantis) still apply.
So while the interface has changed, the workflow hasn’t. That’s what makes Infrastructure-from-Code a practical evolution, as it does not replace how your teams ship infrastructure.
Why Backstage Needs a Plugin
Templates Aren’t Enough
Backstage gives developers a clean way to register services, but when it comes to infrastructure, most plugins just scaffold a Git repo or run a script. It’s like giving someone a blank form instead of a working setup. The heavy lifting, wiring VPCs, writing IAM roles, and setting up CI pipelines is still manual.
Imagine a developer clicks “create service” and lands in a repo full of placeholders:
This isn't self-service. It’s self-maintenance.
What StackGen Adds to the Developer Experience
StackGen plugs into Backstage and replaces those placeholder forms with a real infrastructure interface. When a developer creates a service in Backstage, they get a guided canvas where they can visually define the infrastructure requirements.
Let’s say a data science team wants to deploy a scheduled batch job that loads data from S3, runs Python code, and writes to a database. With StackGen, they open Backstage, select a “Batch Job” blueprint, connect the storage and compute blocks, and customize the schedule. The system generates Terraform, pushes it to Git, and triggers deployment.
The Backstage plugin handles:
- Visual design of infrastructure inside the Backstage UI
- Enforcing team-based templates and cloud standards
- Pushing generated Terraform to the right Git repo
- Triggering GitOps deployment automatically
Hands-On: Using StackGen with Backstage
Once StackGen is installed, Backstage becomes more than a service catalog. It becomes a fully capable interface for modeling, generating, and shipping infrastructure, all from the same place where developers already manage their services. Let’s walk through what this setup looks like in practice.
Install the Plugin and Set Up Access
To get started, you’ll need to add the StackGen plugin to your Backstage instance. The plugin is available by request and integrates directly into the Backstage UI. Plugin installation docs walk through the steps, but the process is straightforward for any team that’s already managing internal plugins.
Authentication is handled via access tokens or OAuth, depending on your setup. OAuth support is currently in progress and will be available in the future. Each Backstage user is mapped to a StackGen role, so permissions are tightly scoped. Platform admins can configure cloud mappings, module versions, and guardrails. Developers can only create and modify blueprints within those bounds.
Org-level configuration for the StackGen plugin is managed inside Backstage’s app-config.yaml. Platform teams specify the StackGen adapter endpoint (baseUrl), an API token for authentication, and optionally an allowedTeams list to scope which teams can create appStacks. This keeps the setup centralised and ensures consistent infrastructure standards across teams while using the same plugin instance.
Design Your Infrastructure Blueprint Visually
- The developer creates or updates a service in Backstage.
- Through the plugin, StackGen receives that metadata and generates a new appStack.
- If a pre-defined infrastructure template exists, the developer can select it via Backstage and initiate an appStack creation.
- From that point onward, the developer switches to the StackGen interface, where the topology is represented visually on the canvas. From here, they can visually connect resources, adjust parameters, and finalize the blueprint.
- Finally, StackGen handles Terraform code generation, Git commit (via PR), and integration with CI/CD tools like Atlantis or ArgoCD.
Generate Terraform and Push to Git
Once the blueprint is ready, the developer clicks “Generate Infrastructure”. StackGen translates the visual Topology into a directory of Terraform code. Each logical component is mapped to a reusable module, and the output is formatted, linted, and structured for review.
Here’s what that output looks like in a generated pull request:
This entire structure is committed to a Git branch using either GitHub or GitLab APIs. Teams can configure branch naming patterns, commit messages, and reviewer auto-assignment. From there, the pull request goes through the same review process as any other infrastructure change.
StackGen doesn’t apply anything automatically. Every change starts in Git.
Trigger GitOps Delivery Through Your CI/CD Tooling
Following a successful merge, StackGen defers to your established CI/CD or GitOps workflow for deployment.
If you're using ArgoCD, it watches the Git repo and automatically syncs the new infrastructure state. Developers don’t need to know anything about Argo; once the code is in Git, Argo applies it according to its sync rules.
If you're using Atlantis, the PR includes a terraform plan comment, and a reviewer can trigger apply with a simple:
atlantis apply
The key here is that StackGen doesn't replace your CI/CD process. It integrates into it. Developers never need to switch tools or context. From visual blueprint to provisioned infrastructure, everything flows through Git, pipelines, and the tools you already use.
How StackGen Compares to Backstage Infra Plugins
Several Backstage plugins claim to support infrastructure provisioning, but most stop at basic scaffolding or form-based input. They don't generate actual infrastructure code, lack GitOps integration, and can’t adapt to real-world cloud complexity.
Here’s how StackGen compares to the most widely known plugins:
Roadie’s plugin mainly provides form-based input that populates static templates. It doesn’t generate code, nor does it manage updates or enforce policies beyond the initial step. Spotify’s Golden Paths are useful for service templates, but they’re mostly focused on application scaffolding, not cloud infrastructure.
StackGen stands out by providing a visual, schema-driven modeling interface, generating real Terraform code, and integrating seamlessly with GitOps pipelines. The combination of developer autonomy and platform governance is what makes it suitable for production-scale infrastructure.
Common Pitfalls and How StackGen Avoids Them
Most infrastructure-as-code workflows fail not because of tooling, but because of process drift, inconsistent standards, or lack of guardrails. StackGen’s design addresses these problems directly by building enforcement and automation into the modeling process.
1. Infrastructure Changes Always Flow Through Git
With many IaC setups, it's easy for drift to creep in. One developer applies changes locally while the other tweaks a module in a different branch. Soon, your deployed infrastructure no longer matches what’s in your main repo.
StackGen enforces a Git-first workflow. Every blueprint action leads to code generation, a structured commit, and a pull request. There are no one-off applies or silent changes. ArgoCD or Atlantis picks up the code after approval and applies it through your existing GitOps workflow.
That means your Terraform is always the source of truth, and what’s running in production is exactly what’s versioned and reviewed.
2. Naming, Tagging, and Scope Stay Consistent Across Teams
Without strong guardrails, teams end up using inconsistent resource names, mismatched tagging formats, and confusing environments. It might not break anything immediately, but it makes long-term maintenance painful.
In StackGen, platform teams define blueprint-wide rules: how resources are named, which tags are required, what scopes are allowed, and what regions can be used. These conventions are automatically applied during modeling and reflected in the generated code.
Whether it’s a seasoned platform engineer or a new app developer, everyone builds from the same consistent pattern for VPCs, databases, and services alike.
3. Cloud Resources Are Sized with Guardrails, Not Guesswork
Cost overruns often come from misjudged instance sizes, forgotten storage buckets, or unrestricted scaling policies. With StackGen, each blueprint enforces constraints on size, scaling, and runtime configuration.
If a developer tries to select a GPU-optimized instance in a non-production environment, the UI flags it. If a service doesn’t define a budget tag, code generation is blocked. Even before Terraform is committed, StackGen can show projected cost ranges based on current parameters and cloud provider pricing.
It’s not just about budget, it’s about predictability and responsibility during the design phase.
Conclusion
Self-service infrastructure often fails not because of intent, but because the tools assume every developer is an infrastructure expert. Backstage brought consistency to service onboarding, but most plugins stop at scaffolding, leaving Terraform, reviews, and policies as manual overhead.
StackGen closes that gap. It brings a visual modeling experience to Backstage, backed by typed schemas, policy-enforced blueprints, and real Terraform output. Developers get a safe and structured way to provision infrastructure, while platform teams keep full control over modules, standards, and GitOps pipelines.
In this blog, we looked at how StackGen handles complex use cases like multi-cloud setups, team onboarding, and shared services. From real-time validation to commit-time enforcement and CI/CD integrations, StackGen turns infrastructure from a bottleneck into a consistent, repeatable workflow.
FAQs
1. What Is the Stackgen Backstage Plugin, and What Does It Do?
The StackGen Backstage plugin allows developers to create and manage application stacks within Backstage by syncing services and leveraging predefined templates. The plugin enables users to select a template and create an appStack, which can then be pushed to Git and reviewed. Once the appStack is created, StackGen automates the remaining steps to generate production-ready code, streamlining the migration and deployment process.
2. Which Cloud Providers Are Supported by the Stackgen Backstage Plugin?
StackGen currently supports AWS, Azure, and GCP. You can switch providers at the blueprint level, and StackGen will remap resources accordingly.
3. How Does Stackgen Generate Terraform Code From Backstage Metadata?
Each resource in the Topology canvas maps to a typed schema that describes a cloud resource. StackGen builds a dependency graph from this visual blueprint and compiles it into a modular Terraform using approved modules, injects organization-wide policies, and commits the code to Git for review.
4. Is Any Installation or Special Access Required?
The plugin requires integration into your Backstage instance and authentication setup with StackGen. Access is currently available by request, and setup involves configuring org-wide defaults, cloud provider mappings, and access roles.
For access requests or support, contact support@stackgen.com.
5. Does the Backstage System Model Automatically Provide Self-Service Infrastructure?
No, the System Model in Backstage helps visualise service relationships, ownerships, and metadata, but it doesn’t handle infrastructure provisioning by itself. However, with plugins like StackGen, you can extend Backstage to support true self-service infrastructure by connecting system definitions to blueprint-driven IaC generation and Git-based workflows.