Frequently Asked Questions
Templates
Who owns the templates?
Your organization owns the templates. They are stored in a GitHub repository under your organization's GitHub account — not inside the Amnify platform. You have full control to add, modify, or remove templates at any time.
How do I add a new template?
- Author the template in your GitHub repository following the Amnify template structure (your Amnify administrator can provide the authoring guide)
- Commit and push the file to the branch configured as the sync source
- Open Deploy → Templates in Amnify and click Sync Templates
- The new template appears immediately in the library
How do I modify an existing template?
- Edit the template file in your GitHub repository
- Commit and push the change
- Trigger a Sync Templates in Amnify Deploy
- The updated template is immediately available for new deployments
Will modifying a template affect existing deployments?
Existing deployments are not automatically changed when a template is updated. The change takes effect the next time a deployment that uses that template is executed. If you add a new required variable, existing deployments will need to be edited to provide a value for it before they can be executed again.
Can I use a private GitHub repository for templates?
Yes. As long as the GitHub integration in Amnify is configured with the appropriate access permissions, private repositories work the same as public ones.
Projects and Deployments
Can I deploy the same template multiple times?
Yes. A template is a reusable blueprint. You can create as many Deployments from the same template as you need — each is a separate, independent instance with its own variables, cloud environment, and execution history.
Can a Deployment belong to multiple Projects?
No. Each Deployment belongs to exactly one Project. If you need the same infrastructure in multiple projects, create separate Deployments in each project.
Can I move a Deployment from one Project to another?
This is not currently supported. If you need a Deployment in a different project, create a new Deployment in the target project and destroy the original.
Can I edit a Deployment's variables after it has been created?
Yes. Open the Deployment detail page, click Edit, and update the variable values. The changes take effect the next time you execute the deployment — editing does not trigger a new run automatically.
What happens if I edit variables on an already-deployed Deployment?
Editing the variables updates them in Amnify, but does not change the live cloud infrastructure until you execute the deployment again. The next execution will generate a plan showing the difference between the current state and the updated variables.
Can I change the cloud provider or region for an existing Deployment?
No. The cloud provider, region, and account are set at creation time and cannot be changed. To move infrastructure to a different provider or region, create a new Deployment with the correct settings and destroy the original.
Execution and Runs
Can I skip the approval step?
No. Both the plan approval and apply approval are required for every execution. They cannot be skipped or disabled — they protect against accidental or unintended infrastructure changes.
What happens if I cancel a run?
Cancelling at either approval step (Awaiting Plan Approval or Awaiting Apply Approval) aborts the run without making any changes to your cloud infrastructure. Nothing is created, modified, or deleted.
Can I cancel a run while it is applying?
No. Once a run enters the Applying or Destroying state, it cannot be cancelled — changes are already being made to your cloud environment.
What happens when a run fails partway through?
Execution stops at the point of failure. Resources that were created before the failure remain in your cloud. When you re-execute after fixing the issue, the plan will reflect the current state of the infrastructure and only apply the remaining changes — already-created resources will not be duplicated.
Can I re-execute a deployment after it has completed?
Yes. You can execute a deployment as many times as needed. Each execution creates a new Run. If the infrastructure is already in the correct state, the plan will show no changes and the execution will complete quickly.
How long does a typical deployment take?
This depends entirely on the template and the cloud provider. Simple resource creation (e.g., a single storage bucket) may complete in under a minute. Complex stacks (e.g., a Kubernetes cluster with several node pools and networking components) can take 15–30 minutes. The execution log shows real-time progress.
Pipelines
What is the difference between a Deployment Run and a Pipeline Run?
A Deployment Run is a single execution of one Deployment. A Pipeline Run is the execution of an entire Pipeline — it triggers individual Deployment Runs for each Deployment in the pipeline's sequence and tracks them as a group.
Do Deployments in a Pipeline run in parallel?
No. Deployments in a Pipeline always run sequentially — one must complete before the next begins. This is by design: it supports dependency ordering so that earlier deployments succeed before later ones proceed.
Does every Deployment in a Pipeline require approval?
Yes. Each Deployment within a Pipeline run still goes through its own approval workflow — plan approval, then apply approval. You will be prompted to approve each Deployment in turn as the pipeline progresses.
What happens if a Deployment fails in the middle of a Pipeline?
The Pipeline stops at the failing Deployment. Subsequent Deployments in the pipeline are not executed. Fix the issue with the failing Deployment and run the pipeline again — earlier Deployments that already completed successfully will not be re-executed if their infrastructure is already in the correct state.
Can the same Deployment be in multiple Pipelines?
Yes. A Pipeline references Deployments; it does not own them. The same Deployment can appear in any number of Pipelines and can also be executed individually.
Cloud and Infrastructure
Which cloud providers are supported?
Amnify Deploy supports Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).
Where are my cloud credentials stored?
Cloud credentials are stored securely in the Amnify platform as part of the Integrations configuration. They are encrypted at rest and are never exposed in the Deploy interface, logs, or API responses.
What is a "plan" and why does it require approval?
A plan is a detailed preview of every cloud resource that will be created, modified, or deleted if you proceed with a deployment. It is generated by analyzing your template and the variables you provided, without making any actual changes to your cloud.
Requiring approval of the plan ensures that someone with knowledge of the intended infrastructure reviews what will happen before irreversible changes are made. This is a standard best practice for infrastructure-as-code workflows.
Can I use Amnify Deploy for any kind of cloud infrastructure?
Amnify Deploy can provision any infrastructure that can be expressed as a template in your GitHub repository. The range of supported resource types depends on your templates and the underlying cloud providers. If a type of infrastructure is not yet covered by your templates, you can add a new template to your repository.