IaC from Templates
An appStack template is an appStack that you mark as a blueprint. When you use a template to create a new appStack, StackGen copies resources, Environments, Variables, and Locals from that template appStack into the new appStack. After the initial creation, the new appStack operates independently.
Who Can Manage Template Creation
Only Admins and DevOps can create an appStack template (mark an appStack as a template). Developers cannot create templates. Developers can still create new appStacks from templates that already exist.
| Role | Capabilities |
|---|---|
| Admins and DevOps | Mark an appStack as a template (create a template). Create new appStacks from templates. |
| Developers | Create new appStacks from existing templates. Cannot mark an appStack as a template or otherwise create a template. |
How Templates Work
When you create a new appStack from a template, StackGen performs a one-time copy of the template's configuration.
Inheritance and updates
-
Initial copy: The new appStack inherits all Environments, Variables, and Locals exactly as they are saved in the template.
-
No auto-updates: If you change a template later, existing appStacks created from it do not change. Only new appStacks created after the update will reflect the changes.
-
Project scope: Templates are only available within the Project where they were created. They are not shared across your entire organization (tenant). This applies even to templates created in a Personal Workspace.
Snapshots: StackGen does not carry forward snapshot history from the template appStack when you create a new appStack from a template. The new appStack starts its own snapshot timeline after create. For how snapshots work on an appStack, see Snapshots.
Comparison with resource packs
appStack templates and resource packs both reuse saved work, but they fit different steps. Use the table below to choose the right path.
| Feature | appStack template | Resource pack |
|---|---|---|
| Best use case | Start a complete new layout when you create an appStack (copy from a marked template). | Add specific groups of resources to an existing layout. |
| Limitation | Scoped to a single project (not tenant-wide). | Limited by technical constraints documented for packs; not a full substitute for copying an entire appStack. Project boundaries can affect packs that depend on project-specific modules. |
Pick templates for a new appStack that follows the same blueprint. Pick resource packs for adding a standard resource bundle to an appStack you already have, and plan around one project and pack limits either way.
Template Creation and Usage
Click to view
Mark an appStack as a template
Admins and DevOps can mark an appStack as a template. Developers cannot.
You can mark an appStack as a template in any of these ways:
- Update appStack Name dialog: Open Update appStack Name for the appStack and select Mark as template.
- appStack actions menu: Open the appStack actions menu and choose Mark as template.
- Label: Add a label named
templateto the appStack.
Create a new appStack from a template
To use an appStack template and create a new appStack from it, follow these steps:
- In the left navigation, open appStacks.
- Click + New appStack.
- Choose the flow that starts from a template. Your tenant may show Start from abstract template, Start from appStack templates, or similar wording for the same option.
- Select a template from the list. StackGen copies the template's resources, Environments, Variables, and Locals into the new appStack.
The screenshots below show the Create new appStack flow. The product title bar may read Create new appStack on your tenant; wording can vary slightly elsewhere too.
The first image shows Start from scratch (pick a cloud provider for a blank appStack), Start from appStack templates (or Start from abstract template on some tenants), and the in-product Create appStack Templates note that explains adding the template label to an appStack so it can be used as a template.
The second image shows Search templates, a template card (with a template label on the card), and the confirmation after you pick a template to create a new appStack.


Templates and Project Environment Configuration
Project-level Environment Configuration is not applied when you create from a template. For that flow, StackGen only copies what is saved on the template appStack: Environments, Variables, Locals, and resources.
Environment Configuration under Project Settings can still define defaults for the project, but it is not merged in so that missing items on the template are filled from the project. If something is not on the template appStack at create time, do not expect it to appear on the new appStack because of project settings alone.
How this shows up in two common cases:
-
Environment Configuration is set for the project, and you create or maintain a template appStack that still includes the environments and variables you want. You mark that appStack as a template. New appStacks created from it receive Environments, Variables, Locals, and resources as saved on the template. The result may look like the project defaults because the template appStack actually contains them, not because StackGen merged Environment Configuration during create-from-template.
-
Environment Configuration is set for the project, but you removed default environments, variables, or related configuration from the template appStack (for example you deleted an environment that still exists at the project level). New appStacks created from that template do not get those removed items back from project Environment Configuration. They only get what remained on the template when the copy ran.
After create, check the new appStack's Environments, Variables, and Locals yourself. Do not assume they match Environment Configuration if the template appStack was edited away from those defaults.
Limitations
Project boundaries: Templates stay inside the project where they were created (see Project scope under How templates work). They are not shared tenant-wide. If a template depends on modules, credentials, or settings that exist only in that project, you may see failures or gaps when you try to reuse the same idea elsewhere without aligning those dependencies.
Best Practices for appStack Templates
Manage permissions and labeling
Manage permissions and labeling
- Have Admins or DevOps own creating templates (marking appStacks as templates). Developers cannot create templates, so keep initial blueprint setup and use of the
templatelabel with those roles. - Use the
templatelabel in a consistent way (along with Mark as template if you use it) so templates are easier to find and audit across projects.
Keep the template accurate before you mark it
Keep the template accurate before you mark it
- Before you select Mark as template, confirm Environments, Variables, and Locals on that appStack match what every new appStack should inherit. appStacks that were already created from the template do not update when you change the template later.
Align with environment configuration
Align with environment configuration
- Creates from a template follow the template appStack, not a full merge with Environment Configuration. If new appStacks must include specific project-style variables or environments, add them on the template appStack before others create from it.
Respect project scope
Respect project scope
- Maintain a template in each project that needs it. Templates are not tenant-wide, so copy or recreate the blueprint per project as required.
- When you design a template, only use modules and credentials you know that project can access. Templates tied to Personal Workspace still follow project listing and use rules.
Verify each new appStack
Verify each new appStack
- Right after create, review Topology and Environment settings on the new appStack. Templates can diverge from project defaults; a short audit catches missing variables or environments early.
When to use templates vs resource packs
When to use templates vs resource packs
- Use templates when you need a full starting layout for a new appStack.
- Use resource packs when you need reusable resource bundles on an existing appStack and a full appStack copy is not required. See Comparison with resource packs.