Skip to main content
phala_app is the primary lifecycle resource in the Phala Cloud Terraform provider. It manages a single application identity (app_id) with shared Docker Compose configuration, shared environment variables, and one or more CVM replicas. This is the resource you use for every deployment.

Example Usage

Required Attributes

Optional Attributes

Placement and Identity

Infrastructure

Compose Runtime Settings

These attributes control compose-level runtime behavior. Changing any of them triggers a compose update and CVM restart.

Compose Settings, Init Scripts, Annotations and Launch Token

These attributes are in the provider’s unreleased changes (after 0.3.0-beta.4). No released provider version has them yet.
The provider sends every compose change of one apply as a single PATCH /cvms/{id} merge patch. Only changed keys are sent, and compose keys the provider does not manage stay as they are. The provider keeps these settings as configured in state and does not read them back from Phala Cloud. Changing port_policy, swap_size, storage_discard, snapshotter, event_log_version, requirements (except gpu_policy) or init_scripts updates the app in place and restarts its running CVMs. annotations are applied to the bootstrap CVM at create. A change replaces the whole map on the app’s existing CVMs, without a restart or a compose change. CVMs added later, such as phala_app_instance slots, start without them. Removing the attribute clears them. Changing launch_token sets the new token on the app first, then updates each CVM’s requirements.launch_token_hash. A CVM that restarts in between fails to boot until its compose is updated. Removing it removes the hash from every CVM, then clears the token.

Environment Variables

The provider offers two modes for managing environment variables. You must pick one — they cannot be combined in the same resource. Auto-encryption mode (recommended):
Even in auto-encryption mode, plaintext values are stored in your Terraform state file. If you cannot tolerate plaintext in state storage, use manual encrypted mode instead.
Manual encrypted mode:
On-chain KMS fields (advanced):

Wait Behavior

Setting wait_for_ready = true is recommended for production workflows. Without it, Terraform returns immediately after the API call, and subsequent resources that depend on the endpoint may see incomplete values.

Read-Only (Computed) Attributes

Lifecycle Behavior

Force-New Fields

Changing any of these attributes destroys the existing resource and creates a new one:
  • name
  • region
  • listed
  • ssh_authorized_keys
  • storage_fs
  • kms
  • custom_app_id
  • nonce
  • node_id
  • runner, bash_script and requirements.gpu_policy (unreleased, see above)

In-Place Updates

These attributes can be updated without replacement:
  • size (CPU/RAM changes)
  • disk_size (grow only)
  • image (OS image swap via API patch)
  • docker_compose
  • pre_launch_script
  • replicas
  • env / encrypted_env
  • Compose runtime settings (public_logs, public_sysinfo, public_tcbinfo, gateway_enabled, secure_time)
  • Unreleased: the compose settings, init_scripts, annotations and launch_token described above

Replica Scaling

Set replicas to scale your app horizontally. All replicas share the same compose file, environment, and settings. The provider manages replica creation and deletion to match your desired count.

Create Flow

The provider follows Phala’s two-step API: first POST /cvms/provision to allocate resources, then POST /cvms to commit the deployment. This happens automatically during terraform apply.