Most platform teams are running the same playbook they wrote three years ago: developer opens a ticket, platform engineer interprets it, hand-crafts Terraform, waits for a review, deploys. Repeat for every environment, every service, every team. It worked when you had five services. It doesn't work when you have fifty.
The teams moving away from that model aren't doing it because self-service is a cool idea. They're doing it because platform engineers were spending 60–70%+ of their sprint capacity on interrupt-driven fulfillment requests instead of building the platform itself.
If you've spent a Friday untangling a state file conflict while three developers wait on their environments — or explained to your security team why a policy violation made it to prod — you'll appreciate this setup: a self-service AWS infrastructure workflow built with StackGen, combining a published Terraform module catalog, self-enforcing governance policies, a golden-path AppStack template, and an AI layer that generates environments from plain English. The whole setup takes under 15 minutes.
Prerequisites:
Verify if all tools are installed:
Log in to your StackGen instance, open Enterprise Configuration → Settings → All Projects, and create a new project. Use a consistent naming convention — your GitHub handle works well (e.g., jdoe-project). This project is your isolated workspace — all AppStacks, modules, and governance policies live here.
Generate a Personal Access Token (PAT) from Settings → Personal Access Tokens. Save it immediately — you won't see it again.
Configure the StackGen CLI:
Confirm authentication:
This is where the self-service foundation gets built. Instead of a platform engineer fielding requests and writing Terraform per team, you publish approved modules once, and developers drag them onto a canvas. No Terraform knowledge required on their end. No context-switching required on yours.
Publish four modules for a standard containerized AWS application:
Once uploaded, these modules appear in the StackGen InfraComposer catalog — immediately available to any developer in your project.
Automate module publishing: Add STACKGEN_URL and STACKGEN_TOKEN as GitHub Actions secrets in your module repository. Every merge to main automatically publishes the updated version. One less manual step in the workflow.
The usual failure mode with self-service is governance: you give developers the keys, someone spins up a DynamoDB table with PROVISIONED billing mode, and now you own that cost overrun in the next budget review.. StackGen governance policies run at plan time — the deployment fails before it ever reaches production.
Navigate to Enterprise Configuration → Governance, create a new configuration, and select AWS services. At Step 4 (Select Security Policies), click + Add New Policy and describe the rule in plain English:
"Enforce that all AWS DynamoDB tables use PAY_PER_REQUEST billing mode."
StackGen's AI generates the policy structure from that description.
Critical: Check the resource_type field in the generated rego policy (typically line 6). It must exactly match the Terraform resource type in your module — for example, aws_dynamodb_table. A mismatch means the policy won't evaluate against your actual resources.
Add the AWS provider block:
Scope the policy to your project in the "Enforce on projects" dropdown, then save. Every AppStack deployment in this project is now validated against this policy before apply runs.
A golden template AppStack is the infrastructure pattern you want developers to use by default — the one that already has the right compute, data, and secrets layers wired together. Developers instantiate it with their own variable values; the underlying architecture doesn't change.
In the StackGen UI, create a new AppStack, select AWS, and name it descriptively (your-name-golden-path). Using the InfraComposer canvas, drag the following modules from the catalog:
Name resources consistently (workshop-app, workshop-table, workshop-secret) and save.
IDE shortcut: If you've installed the StackGen MCP server in VS Code, Cursor, or Claude Code, describe the AppStack in your IDE chat — Aiden composes the canvas for you without leaving the editor.
Run a plan to validate the AppStack before converting it to a template:
This is the step that eliminates the ticket queue. Templates are golden path AppStacks with input variables — developers instantiate one with their own values and get a unique environment that inherits all your architectural standards automatically.
Every environment derived from this template now inherits the same architecture, governance policy, and security posture — only the variable values differ between teams.
The last piece is the natural language layer. Developers who don't know which modules to pick, or don't want to navigate a canvas, can describe what they need in plain English — and get a provisioned AppStack back.
Navigate to the StackGen AI console (your-instance.cloud.stackgen.com/ai/), create a workspace attached to your project, and connect the StackGen integration with your instance URL and PAT.
Under Skills, create a new skill:
Skill prompt:
Save the skill. Developers can now type:
"Create infrastructure for my new payment service."
Aiden generates a fully-configured, governance-compliant AppStack and hands back a direct link. No ticket, no platform engineer in the loop, no Terraform required. What used to take 3 days and a Slack thread now takes 90 seconds.
Note: In environments where ticketing is still required, Aiden can directly integrate with ServiceNow to process developer requests.
With the plan reviewed, deploy:
App Runner provisioning typically completes in 3–5 minutes.
To destroy the environment:
Once this is running, the platform team's relationship to infrastructure changes. You stop being a fulfillment queue and start being a standards organization.
For platform engineers building standards: Expand the module catalog with additional golden paths — classic VMs, data platforms, web apps with SQL. Use terraform-importer to onboard existing Terraform projects without rewrites (see Going Further below). Every new pattern you publish becomes immediately available to every developer in the project.
For DevOps engineers managing deployments: Connect the StackGen MCP server to VS Code or Cursor so developers never leave their editor to request infrastructure. Set up GitHub Actions for automatic module publishing on every merge.
For engineering leaders tracking compliance: StackGen governance policies enforce standards at plan time across every AppStack in your project. Audit trails show which template generated each environment and when — useful when a compliance question surfaces at renewal time.
The distinction that matters most in practice: governance enforced at plan time (before apply) versus governance enforced through review processes (after the code is written, before the PR merges). For teams that have been burned by audit findings on manually-deployed infrastructure, that's the difference that drives the decision.
If your team already has Terraform projects created from the community version of Terraform, you don't need to rewrite them. The terraform-importer CLI reads an existing Terraform source directory and creates a StackGen AppStack from it automatically — no manual canvas work required.
Clone the workshop examples repo to try it:
Then import one of the example projects:
If you have the StackGen MCP server installed in VS Code or Cursor, you can describe the import in your IDE chat, and Aiden handles the entire operation — no CLI commands needed.
Once imported, the AppStack lives in your project catalog alongside everything you built in the steps above. From there, you can mark it as a template, attach governance policies, and make it self-serviceable for other teams — the same workflow, applied to code that already exists.
Ready to build your self-service platform? Get started with StackGen or book some time with our team. We're happy to walk through your setup.