Skip to main content
This page covers every variable type Amnify renders, with paired .tftemplate.json examples, and the encryption flow for sensitive variables. For the field-by-field manifest reference, see template.json Reference. This page is the practical companion: how each type actually behaves.

string

The default. Renders a single-line text input. With options, renders a dropdown. With sensitive: true, renders a masked password field.

Plain string

String with dropdown (options)

The user’s choice is passed to Terraform verbatim — no transformation. Choose options values that are also valid Terraform inputs (e.g. AWS region codes, Azure region names).

number

Numeric input, parsed and serialized as a JSON number.
For range checks, use a validation block in your .tf file:

bool

Renders as a toggle / checkbox.
Booleans pair well with condition to reveal advanced fields only when the toggle is on. See the Conditional Visibility section.

object

A group of nested fields. Use it when you have a logical sub-structure (e.g. a “backup config” with retention + window + geo flags) that is always present as a single unit.
If the object is optional in template.json ("required": false), use default = null (or optional(object({...}))) in Terraform.

list(object)

A repeating group of nested fields. Renders with add and remove controls in the UI. Use it for things like “list of subnets”, “list of firewall rules”, “list of IAM bindings”.
min_items enforces “at least N entries” in the UI. There is no max_items field today — use Terraform validation if you need an upper bound.

Nesting list(object) inside list(object)

You can nest as deeply as you need. The shipped AWS VPC template does this for NACL ingress/egress rules: each subnet has an optional NACL object, which contains a list of ingress rules and a list of egress rules.
The matching Terraform uses optional(...) for non-required nested objects:

Sensitive Variables

Setting "sensitive": true in template.json triggers Amnify’s secret-handling pipeline. Here is exactly what happens: Key properties:
  • Plaintext is never persisted. Only the encrypted iv:authTag:ciphertext triple lives in the database, in the sensitive_variables JSON column on the deployment row.
  • Encryption key is org-scoped. Each organization has its own salt; values cannot be decrypted across orgs.
  • Decryption happens once, in memory, just before terraform.tfvars.json is written. The plaintext exists only inside the deploy worker process, for the duration of one deployment run.
  • The UI never re-displays the plaintext. Once submitted, users see a masked indicator. To change the value, they enter a new one — they cannot retrieve the old one.

Declaring a sensitive variable

The sensitive = true on the Terraform side is independent of Amnify’s encryption — it just prevents Terraform from printing the value in plan/apply logs. Set both: sensitive in JSON for Amnify storage, and sensitive = true in .tf for Terraform log hygiene.

Sensitive outputs

If a deployment produces a secret value (e.g. a generated connection string), mark the output as sensitive:
The Amnify UI will mask sensitive outputs by default; users can reveal them with an explicit click.

Auto-Injected Variables

Amnify merges several values into terraform.tfvars.json automatically. You declare a variable block for them in your .tf file, but you do not add them to template.json: If you want users to override one of these per deployment, add a matching entry to template.json — the user-supplied value takes precedence in the merge.

Next Steps