Making Terraform Accessible: How Internal Developer Platforms (like GitOps Director) Enable True GitOps Self-Service

In Part 1 of this series, From Ticket-Ops to Platform Engineering, we established the core problems: how ticket-driven infrastructure provisioning breaks modern delivery pipelines and why scaling automation requires a fundamental architectural shift. We’ve discussed the importance of decentralized state management and the transition to GitOps workflows.

But for many engineering organizations, the hardest part remains. How do you make this new, scalable architecture accessible to your developers without forcing them to become Terraform, Ansible, or Argo CD experts? How do you move from a centralized, complex infrastructure pipeline to a true developer self-service experience?

The answer is an Internal Developer Platform (IDP). In this final part, we explore why a framework alone isn’t enough, and how a specialized solution like GitOps Director bridges the gap between raw automation code and a satisfying developer experience.

Why Backstage is a Great Framework (But Not a Complete Solution)

When building an IDP, the engineering community has widely rallied around Spotify Backstage. Backstage is an open-source framework for building developer portals. It is an excellent framework for a few key reasons:

• Plugin Architecture: It’s modular, allowing teams to build and integrate custom solutions.
• Centralizing View: Backstage serves as a single pane of glass, bringing together software catalogs, API definitions, and documentation.
• Service Catalog: Its powerful catalog can map every software entity and its dependencies across the entire organization.

However, many teams learn a frustrating lesson when trying to use Backstage for true infrastructure self-service.

The Backstage OOTB Problem: Where GitOps Fails

While Backstage excels at cataloging and viewing, its built-in „scaffolder“ and other out-of-the-box (OOTB) capabilities are not satisfying GitOps solutions for robust infrastructure provisioning. When you rely on Backstage OOTB, you run into significant limitations:

1. Simple Scaffolder is Not Dynamic: Backstage OOTB templates are typically static. They just copy-paste a predefined directory structure. True self-service requires dynamically generating a unique module structure for that specific application, environment, and user-provided input.
2. Manual Deployment Setup: Backstage can push initial code to Git. But it often leaves the platform team with the task of manually setting up the CI/CD pipeline, configuring access, and creating the necessary infrastructure state files for that specific module.
3. Missing GitOps Reconciliation: Backstage doesn’t natively reconcile the Git state. It’s a portal, not a GitOps operator. Relying on simple CI triggers (e.g., commit to main) often fails at scale due to concurrent execution, state locking issues, and a lack of true RBAC boundary for Terraform execution.

In short, Backstage OOTB gives you a nice form to start, but it leaves you back in the manual operations world for Day-2 Operations (updates, upgrades, deletions).

Enter GitOps Director: Enabling True GitOps Self-Service

To overcome these OOTB limitations, you need an orchestrator that connects the Backstage UI to your automation tools and GitOps pipelines. This is why we designed GitOps Director.

GitOps Director is not just a form; it is a true GitOps self-service solution that orchestrates the entire lifecycle:

1. Dynamic Module Generation (Not Templates)

When a developer selects a template via Backstage, GitOps Director doesn’t just copy code. It generates a unique, module-compliant Terraform HCL directory structure specifically for that request. The variables provided by the developer are dynamically injected into the generated IaC code, which is then structured to support decentralized state management.

2. Managing the Day-2 Operations and Lifecycle

Day-2 Operations (updates, scaling, deletions) are often an afterthought. A true IDP must manage the entire lifecycle. With GitOps Director, if a developer needs to scale a node pool, upgrade a database version, or even decommission a cluster, they use the same self-service form in Backstage. GitOps Director understands the existing state and generates the precise Pull Request (PR/MR) to update the declarative code, triggering the automated GitOps workflow.

Detailed Explanation of the GitOps Director Integration Diagram

Let’s dive into the core orchestration paths that GitOps Director (acting as the IDP’s engine behind Backstage) uses to make different toolsets accessible as self-service. The diagram illustrates how a unified, developer-friendly request is translated into technically varied, but consistently governed, GitOps workflows.

Flow 1: Terraform via CI System (e.g., GitLab Runner)

This is the classic, powerful path for infrastructure-as-code.

1. Developer Action: The developer makes a request (e.g., „GKE Cluster“) in the Backstage UI, which is abstracted by GitOps Director.
2. GitOps Director Orchestration: GitOps Director dynamically generates the Terraform HCL code. It opens a Pull Request (PR/MR) in the specified repository. Approval is done via Git or can be extended with Third-Party tools like ServiceNow.
3. Automated Execution: GitOps Director provides insights in the execution of the pipeline, including status, logs or security logs.
4. Result: When merged, the infrastructure is deployed to the Destination Platform (e.g., Google Cloud). Developers get infrastructure in minutes, and Ops has a governed, secure, micro-state workflow.

Flow 2: Argo Application via Argo CD App-of-Apps

This Kubernetes-native path abstracts cluster application management.

1. Developer Action: The developer requests an application (e.g., „Production Microservice Environment“).
2. GitOps Director Orchestration: GitOps Director does not generate raw HCL. Instead, it generates the declarative Argo Application definition and K8s manifests for the request. It pushes this definition to Git and opens a PR.
3. Automated Execution: The primary Argo CD App-of-Apps controller detects the new definition. Since it is declarative, Argo CD automatically creates the necessary child applications.
4. Result: The application is reconciled (deployed) into the Kubernetes clusters on the Destination Platform.

Flow 3: RAW-Format via Argo CD ApplicationSet

This is an advanced flow for Kubernetes workloads with maximum flexibility.

1. Developer Action: The developer makes a complex multi-environment request.
2. GitOps Director Orchestration: For maximum flexibility, GitOps Director supports pushing the raw application configuration files (e.g., plain YAML manifests or Helm values files) to a specific directory in Git. It opens a PR.
3. Automated Execution: The Argo CD ApplicationSet controller monitors this directory. Using generator patterns, it automatically generates a unique Argo Application for each folder (each application/environment).
4. Result: The applications are reconciled across any number of target Kubernetes clusters. This gives Platform teams deep control while providing a unified self-service view to the developer.

Flow 4: Ansible Playbook via CI System (e.g., GitLab Runner)

This flow mirrors Terraform, making configuration management accessible.

1. Developer Action: The developer needs configuration changes on a sovereign VMware VM or a dedicated middleware setup.
2. GitOps Director Orchestration: GitOps Director dynamically generates the required Ansible Playbook and inventory configuration. It opens a PR.
3. Automated Execution: A dedicated CI runner (scoped for that playbook) is used to execute the ansible-playbook command. Governance and policy checks are applied to the PR.
4. Result: The configuration is applied directly to the VMs on the sovereign, on-premises Destination Platform. Developers use the same IDP, regardless of the underlying tool.

Flow 5: Ansible Playbook via Ansible Automation

This flow shows the power of tool-agnostic orchestration.

1. Developer Action: Same as Flow 4, but for an organization that has already invested deeply in Ansible Automation Platform (AAP) or Ansible Tower.
2. GitOps Director Orchestration: GitOps Director abstracts this operational choice. It still generates the playbook and inventory to Git via a PR, but instead of using a CI runner, a standardized WebHook is used directly to the organization’s existing Ansible Automation platform.

How GitOps Director Features Solved Traditional Problems

By enabling this level of orchestration, GitOps Director acts as the final synthesis for Platform Engineering, directly solving the traditional problems we’ve discussed throughout this series:

1. Golden Paths & Standardisation: Instead of relying on a human to manually enforce a standard, GitOps Director exposes curated, pre-approved modules from your central private registry as the only available templates. This ensures all infrastructure is compliant by design.
2. RBAC & Security Boundary: Developers cannot trigger Terraform directly. GitOps Director operates via Pull Requests. It ensures that only the authorized CI runner, with the precise, narrow IAM boundary (a sovereign security design), can execute the IaC code. Security becomes a shift-left, policy-as-code certainty.
3. Multi-Cloud Sovereignty and No Lock-in: The IDP acts as an abstraction layer. A developer requests a „Database,“ and the IDP, powered by GitOps Director, intelligently determines whether this should be provisioned via Terraform on AWS, or via Ansible on a local, sovereign VMware data center or somewhere else. Your declarative definitions remain in your independent Git history, giving you true ownership and preventing vendor lock-in.

The Conclusion: Speed Meets Sovereignty

The transition from Ticket-Ops to Platform Engineering is not just a tooling upgrade; it is a cultural and architectural evolution. It requires moving away from manual gatekeeping to automated guardrails, from monolithic states to decentralized micro-states, and from a centralized bottleneck to empowered developer self-service.

You do not have to choose between developer velocity and enterprise security. With the right architecture—an intelligent IDP powered by specialized tools like GitOps Director—they reinforce each other.

Take back control of your cloud. Built on 15 years of deep enterprise consulting experience at Soeldner Consult, GitOps Director is the specialized engine that transforms Backstage into a powerful IDP. Natively integrated, it abstracts the complexity of Terraform, Ansible, and Argo CD behind a simple, governed self-service interface.