Scaleway Terraform Provider

Use the scaleway_s2s_vpn_customer_gateway data source to retrieve details about an existing Scaleway Site-to-Site VPN customer gateway. You can look up a gateway using either its unique ID or its name.

Note: Customer Gateway IDs are regional and follow the format {region}/{id} (e.g., fr-par/11111111-1111-1111-1111-111111111111).

# Get info by gateway ID
data "scaleway_s2s_vpn_customer_gateway" "my_gateway" {
  customer_gateway_id = "11111111-1111-1111-1111-111111111111"
}

# Get info by name
data "scaleway_s2s_vpn_customer_gateway" "my_gateway" {
  name = "foobar"
}

The scaleway_rdb_instance resource is used to create and manage Scaleway Managed Database (RDB) instances. It supports various database engines (e.g., PostgreSQL, MySQL), high availability (HA) clusters, backup schedules, and custom database settings.

By default, an instance is created with a public load-balancer endpoint. You can optionally configure a private network endpoint or both public and private endpoints.

resource "scaleway_rdb_instance" "main" {
  name               = "test-rdb"
  node_type          = "DB-DEV-S"
  engine             = "PostgreSQL-15"
  is_ha_cluster      = true
  disable_backup     = true
  user_name          = "my_initial_user"
  password           = "thiZ_is_v&ry_s3cret"
  encryption_at_rest = true
}

When configuring a scaleway_datawarehouse_deployment, note the following behavior for scaling and versioning:

• Version: The version argument (e.g., "v25") is required and forces a new resource (recreation) if changed.
• Replicas: replica_count can be updated in place.
• CPU Scaling: cpu_min and cpu_max define the autoscaling bounds. These can be updated in place, but cpu_min must be $\le$ cpu_max.
• Shards: shard_count is computed and immutable; it cannot be changed after creation.
• Running State: The started argument (defaults to true) controls whether the deployment is running. If started is false, the deployment is stopped. Scaling operations (replica_count, cpu_min, cpu_max) require the deployment to be running; if it is stopped, the provider will start it, apply the change, and then stop it again if started is false.

To prevent sensitive passwords from being stored in your Terraform state file, use the password_wo (for the main user) or service_password_wo (for the service user) arguments.

When using write-only mode:

1. Use password_wo instead of password.
2. You must also provide password_wo_version.
3. To update the password, you must change the password_wo_version value.

This same pattern applies to service users via service_password_wo and service_password_wo_version.

The scaleway_secret_version ephemeral resource allows you to access and read secret versions from Scaleway Secret Manager without persisting the secret's payload in your Terraform plan or state files.

This is the recommended way to handle secrets when using the data_wo (write-only) attribute in a scaleway_secret_version resource. By using an ephemeral block instead of a standard data source, you ensure that sensitive data is available during Terraform execution but is never written to the state file, reducing the risk of credential exposure.

ephemeral "scaleway_secret_version" "my_secret_access" {
  secret_id = scaleway_secret.example.id
  revision  = "latest"
}

To connect an instance to a private network, use the private_network block with the pn_id of the target network.

Constraints:

• The instance must be created in the same zone as the private network.
• An instance supports a maximum of 8 different private networks.
• Updates to the private_network block will recreate the private network interface.

resource "scaleway_vpc_private_network" "pn01" {
  name = "private_network_instance"
}

resource "scaleway_instance_server" "base" {
  image = "ubuntu_jammy"
  type  = "DEV1-S"

  private_network {
    pn_id = scaleway_vpc_private_network.pn01.id
  }
}

The rotation_policy block enables automatic key rotation.

• rotation_period (Required): The duration between rotations (e.g., "720h" for 30 days).
• next_rotation_at (Optional): A specific RFC 3339 timestamp for the next rotation.

Important Note on next_rotation_at: If you set this value explicitly, it must be in the future. After a rotation occurs, the API computes a new date. To prevent Terraform from constantly trying to update this value to the new API-computed date, you should use ignore_changes in your resource configuration.

rotation_policy {
  rotation_period = "720h"
  # next_rotation_at is computed by the API if not set
}

The scaleway_key_manager_generate_data_key ephemeral resource creates a new data encryption key intended for cryptographic operations performed outside of Scaleway Key Manager.

Security Workflow:

1. The resource generates a key in both plaintext and ciphertext forms.
2. Never store the plaintext. It is sensitive and should only be used immediately upon creation.
3. Store the ciphertext. This is the encrypted version of your data encryption key. It can be stored safely in your state or other systems.
4. To use the key later, you must use the Scaleway Key Manager Decrypt method, providing the key_id of your master key and the ciphertext generated by this resource.

resource "scaleway_key_manager_generate_data_key" "example" {
  key_id = "your-key-uuid-or-regional-id"
  # Optional: without_plaintext = true
}

Write-only arguments are special attributes used during resource creation and updates that are not stored in the Terraform state and not displayed in Terraform plans or outputs.

When to use them

Use write-only arguments for highly sensitive data like passwords, API keys, or secret values to prevent accidental exposure in state files.

Requirements

• Requires Terraform 1.11.0 or later.
• Because they are not stored in state, they cannot be referenced directly by other resources. To use a value set via a write-only argument in another resource, you must use an ephemeral resource (e.g., ephemeral "scaleway_secret_version").