```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
export CHART_VERSION=0.6.4
```

An SV node includes a CometBFT node so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/cometbft-values.yaml` as follows:

* Replace all instances of `TARGET_CLUSTER` with dev, per the cluster to which you are connecting.
* Replace all instances of `TARGET_HOSTNAME` with dev.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster. Note that `SERIAL_ID` is also used within port numbers in URLs here!
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Replace `YOUR_COMETBFT_NODE_ID` with the id obtained when generating the config for the CometBFT node
* Replace `YOUR_HOSTNAME` with the hostname that will be used for the ingress
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistent storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Uncomment the appropriate `nodeId`, `publicKey` and `keyAddress` values in the `sv1` section as per the cluster to which you are connecting.

<div id="helm-configure-global-domain">
  Please modify the file `splice-node/examples/sv-helm/participant-values.yaml` as follows:
</div>

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace `OIDC_AUTHORITY_LEDGER_API_AUDIENCE` in the `auth.targetAudience` entry with audience for the ledger API. e.g. `https://ledger_api.example.com`. If you are not ready to use a custom audience, you can use the suggested default `https://canton.network.global`.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If you are running on a version of Kubernetes earlier than 1.24, set `enableHealthProbes` to `false` to disable the gRPC liveness and readiness probes.
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistant storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Replace `YOUR_NODE_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/global-domain-values.yaml` as follows:

* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/scan-values.yaml` as follows:

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

An SV node includes a validator app so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/validator-values.yaml` as follows:

* Replace `TRUSTED_SCAN_URL` with the URL of the Scan you host. If you are using the ingress configuration of this runbook, you can use `"http://scan-app.sv:5012"`.
* If you want to configure the audience for the Validator app backend API, replace `OIDC_AUTHORITY_VALIDATOR_AUDIENCE` in the `auth.audience` entry with audience for the Validator app backend API. e.g. `https://validator.example.com/api`.
* If you want to configure the audience for the Ledger API, set the `audience` field in the `splice-app-sv-ledger-api-auth` k8s secret with the audience for the Ledger API. e.g. `https://ledger_api.example.com`.
* Replace `OPERATOR_WALLET_USER_ID` with the user ID in your IAM that you want to use to log into the wallet as the SV party. Note that this should be the full user id, e.g., `auth0|43b68e1e4978b000cefba352`, *not* only the suffix `43b68e1e4978b000cefba352`
* Replace `YOUR_CONTACT_POINT` by the same contact point that you used in `sv-values.yaml`. this, set it to an empty string.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If your validator is not supposed to hold any CC, you should disable the wallet by setting `enableWallet` to `false`. Note that if the wallet is disabled, you shouldn't install the wallet or CNS UIs, as they won't work.

Additionally, please modify the file `splice-node/examples/sv-helm/sv-validator-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with dev.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

The private and public key for your SV are defined in a K8s secret. If you haven't done so yet, please first follow the instructions in the Generating an SV Identity section to obtain and register a name and keypair for your SV. Replace `YOUR_PUBLIC_KEY` and `YOUR_PRIVATE_KEY` with the `public-key` and `private-key` values obtained as part of generating your SV identity.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create secret --namespace sv generic splice-app-sv-key \
    --from-literal=public=YOUR_PUBLIC_KEY \
    --from-literal=private=YOUR_PRIVATE_KEY
```

For configuring your sv app, please modify the file `splice-node/examples/sv-helm/sv-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with dev.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* If you want to configure the audience for the SV app backend API, replace `OIDC_AUTHORITY_SV_AUDIENCE` in the `auth.audience` entry with audience for the SV app backend API. e.g. `https://sv.example.com/api`.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* Please set `synchronizers.current.sequencerPublicUrl` to the URL to your sequencer service in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* Please set `scan.publicUrl` to the URL to your Scan app in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* It is recommended to configure pruning .
* Replace `YOUR_CONTACT_POINT` by a slack user name or email address that can be used by node operators to contact you in case there are issues with your node. If you do not want to share this, set it to an empty string.
* If you would like to redistribute all or part of the SV rewards with other parties, you can fill up the `extraBeneficiaries` section with the desired parties and the percentage of the reward that corresponds to them. Note that the party you register must be known on the network for the reward coupon issuance to succeed. Furthermore, that party must be hosted on a validator node for its wallet to collect the SV reward coupons. That collection will happen automatically if the wallet is running. If it is not running during the time that the reward coupon can be collected, the corresponding reward is marked as unclaimed, and stored in an DSO-wide unclaimed reward pool. The `extraBeneficiaries` can be changed with just a restart of the SV app.
* Optionally, uncomment the line for `initialAmuletPrice` and set it to your desired amulet price. This will create an amulet price vote from your SV with the configured price when onboarded. If not set, no vote will be cast. This can always be done later manually from the SV app UI.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
# Replace MIGRATION_ID with the migration ID of the global synchronizer.
migration:
  # This should stay constant after the introduction of logical synchronizer upgrades.
  id: "MIGRATION_ID"
```

Please modify the file `splice-node/examples/sv-helm/info-values.yaml` as follows:

* Replace `TARGET_CLUSTER` with dev
* Replace `MD5_HASH_OF_ALLOWED_IP_RANGES` with the MD5 hash of the `allowed-ip-ranges.json` file corresponding to the dev network.
* Replace `MD5_HASH_OF_APPROVED_SV_IDENTITIES` with the MD5 hash of the `approved-sv-id-values.yaml` file corresponding to the dev network.
* Replace `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `CHAIN_ID_SUFFIX` with the chain ID suffix of the dev network.
* Uncomment `staging` synchronizer and `legacy` synchronizer sections if you are using them.
* Replace `STAGING_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the staging synchronizer on your target cluster.
* Replace `STAGING_SYNCHRONIZER_VERSION` with the version of the staging synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the legacy synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_VERSION` with the version of the legacy synchronizer on your target cluster.

The [configs repo](https://github.com/global-synchronizer-foundation/configs) contains recommended values for configuring your SV node. Store the paths to these YAML files in the following environment variables:

1. `SV_IDENTITIES_FILE`: The list of SV identities for your node to auto-approve as peer SVs. Locate and review the `approved-sv-id-values.yaml` file corresponding to the network to which you are connecting.
2. `UI_CONFIG_VALUES_FILE`: The file is located at `configs/ui-config-values.yaml`, and is the same for all networks.

These environment variables will be used below.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
export CHART_VERSION=0.6.3
```

An SV node includes a CometBFT node so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/cometbft-values.yaml` as follows:

* Replace all instances of `TARGET_CLUSTER` with test, per the cluster to which you are connecting.
* Replace all instances of `TARGET_HOSTNAME` with test.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster. Note that `SERIAL_ID` is also used within port numbers in URLs here!
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Replace `YOUR_COMETBFT_NODE_ID` with the id obtained when generating the config for the CometBFT node
* Replace `YOUR_HOSTNAME` with the hostname that will be used for the ingress
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistent storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Uncomment the appropriate `nodeId`, `publicKey` and `keyAddress` values in the `sv1` section as per the cluster to which you are connecting.

<div id="helm-configure-global-domain">
  Please modify the file `splice-node/examples/sv-helm/participant-values.yaml` as follows:
</div>

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace `OIDC_AUTHORITY_LEDGER_API_AUDIENCE` in the `auth.targetAudience` entry with audience for the ledger API. e.g. `https://ledger_api.example.com`. If you are not ready to use a custom audience, you can use the suggested default `https://canton.network.global`.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If you are running on a version of Kubernetes earlier than 1.24, set `enableHealthProbes` to `false` to disable the gRPC liveness and readiness probes.
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistant storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Replace `YOUR_NODE_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/global-domain-values.yaml` as follows:

* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/scan-values.yaml` as follows:

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

An SV node includes a validator app so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/validator-values.yaml` as follows:

* Replace `TRUSTED_SCAN_URL` with the URL of the Scan you host. If you are using the ingress configuration of this runbook, you can use `"http://scan-app.sv:5012"`.
* If you want to configure the audience for the Validator app backend API, replace `OIDC_AUTHORITY_VALIDATOR_AUDIENCE` in the `auth.audience` entry with audience for the Validator app backend API. e.g. `https://validator.example.com/api`.
* If you want to configure the audience for the Ledger API, set the `audience` field in the `splice-app-sv-ledger-api-auth` k8s secret with the audience for the Ledger API. e.g. `https://ledger_api.example.com`.
* Replace `OPERATOR_WALLET_USER_ID` with the user ID in your IAM that you want to use to log into the wallet as the SV party. Note that this should be the full user id, e.g., `auth0|43b68e1e4978b000cefba352`, *not* only the suffix `43b68e1e4978b000cefba352`
* Replace `YOUR_CONTACT_POINT` by the same contact point that you used in `sv-values.yaml`. this, set it to an empty string.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If your validator is not supposed to hold any CC, you should disable the wallet by setting `enableWallet` to `false`. Note that if the wallet is disabled, you shouldn't install the wallet or CNS UIs, as they won't work.

Additionally, please modify the file `splice-node/examples/sv-helm/sv-validator-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with test.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

The private and public key for your SV are defined in a K8s secret. If you haven't done so yet, please first follow the instructions in the Generating an SV Identity section to obtain and register a name and keypair for your SV. Replace `YOUR_PUBLIC_KEY` and `YOUR_PRIVATE_KEY` with the `public-key` and `private-key` values obtained as part of generating your SV identity.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create secret --namespace sv generic splice-app-sv-key \
    --from-literal=public=YOUR_PUBLIC_KEY \
    --from-literal=private=YOUR_PRIVATE_KEY
```

For configuring your sv app, please modify the file `splice-node/examples/sv-helm/sv-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with test.global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* If you want to configure the audience for the SV app backend API, replace `OIDC_AUTHORITY_SV_AUDIENCE` in the `auth.audience` entry with audience for the SV app backend API. e.g. `https://sv.example.com/api`.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* Please set `synchronizers.current.sequencerPublicUrl` to the URL to your sequencer service in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* Please set `scan.publicUrl` to the URL to your Scan app in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* It is recommended to configure pruning .
* Replace `YOUR_CONTACT_POINT` by a slack user name or email address that can be used by node operators to contact you in case there are issues with your node. If you do not want to share this, set it to an empty string.
* If you would like to redistribute all or part of the SV rewards with other parties, you can fill up the `extraBeneficiaries` section with the desired parties and the percentage of the reward that corresponds to them. Note that the party you register must be known on the network for the reward coupon issuance to succeed. Furthermore, that party must be hosted on a validator node for its wallet to collect the SV reward coupons. That collection will happen automatically if the wallet is running. If it is not running during the time that the reward coupon can be collected, the corresponding reward is marked as unclaimed, and stored in an DSO-wide unclaimed reward pool. The `extraBeneficiaries` can be changed with just a restart of the SV app.
* Optionally, uncomment the line for `initialAmuletPrice` and set it to your desired amulet price. This will create an amulet price vote from your SV with the configured price when onboarded. If not set, no vote will be cast. This can always be done later manually from the SV app UI.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
# Replace MIGRATION_ID with the migration ID of the global synchronizer.
migration:
  # This should stay constant after the introduction of logical synchronizer upgrades.
  id: "MIGRATION_ID"
```

Please modify the file `splice-node/examples/sv-helm/info-values.yaml` as follows:

* Replace `TARGET_CLUSTER` with test
* Replace `MD5_HASH_OF_ALLOWED_IP_RANGES` with the MD5 hash of the `allowed-ip-ranges.json` file corresponding to the test network.
* Replace `MD5_HASH_OF_APPROVED_SV_IDENTITIES` with the MD5 hash of the `approved-sv-id-values.yaml` file corresponding to the test network.
* Replace `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `CHAIN_ID_SUFFIX` with the chain ID suffix of the test network.
* Uncomment `staging` synchronizer and `legacy` synchronizer sections if you are using them.
* Replace `STAGING_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the staging synchronizer on your target cluster.
* Replace `STAGING_SYNCHRONIZER_VERSION` with the version of the staging synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the legacy synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_VERSION` with the version of the legacy synchronizer on your target cluster.

The [configs repo](https://github.com/global-synchronizer-foundation/configs) contains recommended values for configuring your SV node. Store the paths to these YAML files in the following environment variables:

1. `SV_IDENTITIES_FILE`: The list of SV identities for your node to auto-approve as peer SVs. Locate and review the `approved-sv-id-values.yaml` file corresponding to the network to which you are connecting.
2. `UI_CONFIG_VALUES_FILE`: The file is located at `configs/ui-config-values.yaml`, and is the same for all networks.

These environment variables will be used below.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
export CHART_VERSION=0.6.2
```

An SV node includes a CometBFT node so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/cometbft-values.yaml` as follows:

* Replace all instances of `TARGET_CLUSTER` with main, per the cluster to which you are connecting.
* Replace all instances of `TARGET_HOSTNAME` with global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster. Note that `SERIAL_ID` is also used within port numbers in URLs here!
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Replace `YOUR_COMETBFT_NODE_ID` with the id obtained when generating the config for the CometBFT node
* Replace `YOUR_HOSTNAME` with the hostname that will be used for the ingress
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistent storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Uncomment the appropriate `nodeId`, `publicKey` and `keyAddress` values in the `sv1` section as per the cluster to which you are connecting.

<div id="helm-configure-global-domain">
  Please modify the file `splice-node/examples/sv-helm/participant-values.yaml` as follows:
</div>

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace `OIDC_AUTHORITY_LEDGER_API_AUDIENCE` in the `auth.targetAudience` entry with audience for the ledger API. e.g. `https://ledger_api.example.com`. If you are not ready to use a custom audience, you can use the suggested default `https://canton.network.global`.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If you are running on a version of Kubernetes earlier than 1.24, set `enableHealthProbes` to `false` to disable the gRPC liveness and readiness probes.
* Add `db.volumeSize` and `db.volumeStorageClass` to the values file adjust persistant storage size and storage class if necessary. (These values default to 20GiB and `standard-rwo`)
* Replace `YOUR_NODE_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/global-domain-values.yaml` as follows:

* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity.

Please modify the file `splice-node/examples/sv-helm/scan-values.yaml` as follows:

* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

An SV node includes a validator app so you also need to configure that. Please modify the file `splice-node/examples/sv-helm/validator-values.yaml` as follows:

* Replace `TRUSTED_SCAN_URL` with the URL of the Scan you host. If you are using the ingress configuration of this runbook, you can use `"http://scan-app.sv:5012"`.
* If you want to configure the audience for the Validator app backend API, replace `OIDC_AUTHORITY_VALIDATOR_AUDIENCE` in the `auth.audience` entry with audience for the Validator app backend API. e.g. `https://validator.example.com/api`.
* If you want to configure the audience for the Ledger API, set the `audience` field in the `splice-app-sv-ledger-api-auth` k8s secret with the audience for the Ledger API. e.g. `https://ledger_api.example.com`.
* Replace `OPERATOR_WALLET_USER_ID` with the user ID in your IAM that you want to use to log into the wallet as the SV party. Note that this should be the full user id, e.g., `auth0|43b68e1e4978b000cefba352`, *not* only the suffix `43b68e1e4978b000cefba352`
* Replace `YOUR_CONTACT_POINT` by the same contact point that you used in `sv-values.yaml`. this, set it to an empty string.
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* If your validator is not supposed to hold any CC, you should disable the wallet by setting `enableWallet` to `false`. Note that if the wallet is disabled, you shouldn't install the wallet or CNS UIs, as they won't work.

Additionally, please modify the file `splice-node/examples/sv-helm/sv-validator-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.

The private and public key for your SV are defined in a K8s secret. If you haven't done so yet, please first follow the instructions in the Generating an SV Identity section to obtain and register a name and keypair for your SV. Replace `YOUR_PUBLIC_KEY` and `YOUR_PRIVATE_KEY` with the `public-key` and `private-key` values obtained as part of generating your SV identity.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create secret --namespace sv generic splice-app-sv-key \
    --from-literal=public=YOUR_PUBLIC_KEY \
    --from-literal=private=YOUR_PRIVATE_KEY
```

For configuring your sv app, please modify the file `splice-node/examples/sv-helm/sv-values.yaml` as follows:

* Replace all instances of `TARGET_HOSTNAME` with global.canton.network.digitalasset.com, per the cluster to which you are connecting.
* Replace all instances of `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `SERIAL_ID` with the serial ID of the global synchronizer on your target cluster.
* If you want to configure the audience for the SV app backend API, replace `OIDC_AUTHORITY_SV_AUDIENCE` in the `auth.audience` entry with audience for the SV app backend API. e.g. `https://sv.example.com/api`.
* Replace `YOUR_SV_NAME` with the name you chose when creating the SV identity (this must be an exact match of the string for your SV to be approved to onboard)
* Update the `auth.jwksUrl` entry to point to your auth provider's JWK set document by replacing `OIDC_AUTHORITY_URL` with your auth provider's OIDC URL, as explained above.
* Please set `synchronizers.current.sequencerPublicUrl` to the URL to your sequencer service in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* Please set `scan.publicUrl` to the URL to your Scan app in the SV configuration. If you are using the ingress configuration of this runbook, you can just replace `YOUR_HOSTNAME` with your host name.
* It is recommended to configure pruning .
* Replace `YOUR_CONTACT_POINT` by a slack user name or email address that can be used by node operators to contact you in case there are issues with your node. If you do not want to share this, set it to an empty string.
* If you would like to redistribute all or part of the SV rewards with other parties, you can fill up the `extraBeneficiaries` section with the desired parties and the percentage of the reward that corresponds to them. Note that the party you register must be known on the network for the reward coupon issuance to succeed. Furthermore, that party must be hosted on a validator node for its wallet to collect the SV reward coupons. That collection will happen automatically if the wallet is running. If it is not running during the time that the reward coupon can be collected, the corresponding reward is marked as unclaimed, and stored in an DSO-wide unclaimed reward pool. The `extraBeneficiaries` can be changed with just a restart of the SV app.
* Optionally, uncomment the line for `initialAmuletPrice` and set it to your desired amulet price. This will create an amulet price vote from your SV with the configured price when onboarded. If not set, no vote will be cast. This can always be done later manually from the SV app UI.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
# Replace MIGRATION_ID with the migration ID of the global synchronizer.
migration:
  # This should stay constant after the introduction of logical synchronizer upgrades.
  id: "MIGRATION_ID"
```

Please modify the file `splice-node/examples/sv-helm/info-values.yaml` as follows:

* Replace `TARGET_CLUSTER` with main
* Replace `MD5_HASH_OF_ALLOWED_IP_RANGES` with the MD5 hash of the `allowed-ip-ranges.json` file corresponding to the main network.
* Replace `MD5_HASH_OF_APPROVED_SV_IDENTITIES` with the MD5 hash of the `approved-sv-id-values.yaml` file corresponding to the main network.
* Replace `MIGRATION_ID` with the migration ID of the global synchronizer on your target cluster.
* Replace all instances of `CHAIN_ID_SUFFIX` with the chain ID suffix of the main network.
* Uncomment `staging` synchronizer and `legacy` synchronizer sections if you are using them.
* Replace `STAGING_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the staging synchronizer on your target cluster.
* Replace `STAGING_SYNCHRONIZER_VERSION` with the version of the staging synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_MIGRATION_ID` with the migration ID of the legacy synchronizer on your target cluster.
* Replace `LEGACY_SYNCHRONIZER_VERSION` with the version of the legacy synchronizer on your target cluster.

The [configs repo](https://github.com/global-synchronizer-foundation/configs) contains recommended values for configuring your SV node. Store the paths to these YAML files in the following environment variables:

1. `SV_IDENTITIES_FILE`: The list of SV identities for your node to auto-approve as peer SVs. Locate and review the `approved-sv-id-values.yaml` file corresponding to the network to which you are connecting.
2. `UI_CONFIG_VALUES_FILE`: The file is located at `configs/ui-config-values.yaml`, and is the same for all networks.

These environment variables will be used below.

Install the Canton and CometBFT components:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install global-domain-${SERIAL_ID}-cometbft oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cometbft -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/cometbft-values.yaml --wait
helm install global-domain-${SERIAL_ID} oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-global-domain -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/global-domain-values.yaml --wait
```

Note that we use the serial ID when naming Canton synchronizer components. This is to support operating multiple instances of these components side by side as part of a logical synchronizer upgrade.

Install the participant:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install participant oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-participant -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/participant-values.yaml --wait
```

Install the SV node apps:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-sv-node -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-values.yaml -f ${SV_IDENTITIES_FILE} -f ${UI_CONFIG_VALUES_FILE} --wait
helm install scan oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-scan -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/scan-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
helm install validator oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-validator -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/validator-values.yaml -f splice-node/examples/sv-helm/sv-validator-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
```

Install the INFO app, which is used to provide information about the SV node and its configuration:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install info oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-info -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/info-values.yaml
```

Once everything is running, you should be able to inspect the state of the cluster and observe pods running in the new namespace. A typical query might look as follows:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
$ kubectl get pods -n sv
NAME                                         READY   STATUS    RESTARTS      AGE
apps-pg-0                                    2/2     Running   0             14m
ans-web-ui-5cf76bfc98-bh6tw                  2/2     Running   0             10m
global-domain-0-cometbft-c584c9468-9r2v5     2/2     Running   2 (14m ago)   14m
global-domain-0-mediator-7bfb5f6b6d-ts5zp    2/2     Running   0             13m
global-domain-0-sequencer-6c85d98bb6-887c7   2/2     Running   0             13m
info-9fb7bc859-27226                         2/2     Running   0             10m
mediator-pg-0                                2/2     Running   0             14m
participant-0-57579c64ff-wmzk5               2/2     Running   0             14m
participant-pg-0                             2/2     Running   0             14m
scan-app-b8456cc64-stjm2                     2/2     Running   0             10m
scan-web-ui-7c6b5b59dc-fjxjg                 2/2     Running   0             10m
sequencer-pg-0                               2/2     Running   0             14m
sv-app-7f4b6f468c-sj7ch                      2/2     Running   0             13m
sv-web-ui-67bfbdfc77-wwvp9                   2/2     Running   0             13m
validator-app-667445fdfc-rcztx               2/2     Running   0             10m
wallet-web-ui-648f86f9f9-lffz5               2/2     Running   0             10m
```

Note also that `Pod` restarts may happen during bringup, particularly if all helm charts are deployed at the same time. The `splice-sv-node` cannot start until `participant` is running and `participant` cannot start until `postgres` is running.

Install the Canton and CometBFT components:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install global-domain-${SERIAL_ID}-cometbft oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cometbft -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/cometbft-values.yaml --wait
helm install global-domain-${SERIAL_ID} oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-global-domain -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/global-domain-values.yaml --wait
```

Note that we use the serial ID when naming Canton synchronizer components. This is to support operating multiple instances of these components side by side as part of a logical synchronizer upgrade.

Install the participant:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install participant oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-participant -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/participant-values.yaml --wait
```

Install the SV node apps:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-sv-node -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-values.yaml -f ${SV_IDENTITIES_FILE} -f ${UI_CONFIG_VALUES_FILE} --wait
helm install scan oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-scan -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/scan-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
helm install validator oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-validator -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/validator-values.yaml -f splice-node/examples/sv-helm/sv-validator-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
```

Install the INFO app, which is used to provide information about the SV node and its configuration:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install info oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-info -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/info-values.yaml
```

Once everything is running, you should be able to inspect the state of the cluster and observe pods running in the new namespace. A typical query might look as follows:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
$ kubectl get pods -n sv
NAME                                         READY   STATUS    RESTARTS      AGE
apps-pg-0                                    2/2     Running   0             14m
ans-web-ui-5cf76bfc98-bh6tw                  2/2     Running   0             10m
global-domain-0-cometbft-c584c9468-9r2v5     2/2     Running   2 (14m ago)   14m
global-domain-0-mediator-7bfb5f6b6d-ts5zp    2/2     Running   0             13m
global-domain-0-sequencer-6c85d98bb6-887c7   2/2     Running   0             13m
info-9fb7bc859-27226                         2/2     Running   0             10m
mediator-pg-0                                2/2     Running   0             14m
participant-0-57579c64ff-wmzk5               2/2     Running   0             14m
participant-pg-0                             2/2     Running   0             14m
scan-app-b8456cc64-stjm2                     2/2     Running   0             10m
scan-web-ui-7c6b5b59dc-fjxjg                 2/2     Running   0             10m
sequencer-pg-0                               2/2     Running   0             14m
sv-app-7f4b6f468c-sj7ch                      2/2     Running   0             13m
sv-web-ui-67bfbdfc77-wwvp9                   2/2     Running   0             13m
validator-app-667445fdfc-rcztx               2/2     Running   0             10m
wallet-web-ui-648f86f9f9-lffz5               2/2     Running   0             10m
```

Note also that `Pod` restarts may happen during bringup, particularly if all helm charts are deployed at the same time. The `splice-sv-node` cannot start until `participant` is running and `participant` cannot start until `postgres` is running.

Install the Canton and CometBFT components:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install global-domain-${SERIAL_ID}-cometbft oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cometbft -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/cometbft-values.yaml --wait
helm install global-domain-${SERIAL_ID} oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-global-domain -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/global-domain-values.yaml --wait
```

Note that we use the serial ID when naming Canton synchronizer components. This is to support operating multiple instances of these components side by side as part of a logical synchronizer upgrade.

Install the participant:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install participant oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-participant -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/participant-values.yaml --wait
```

Install the SV node apps:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-sv-node -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-values.yaml -f ${SV_IDENTITIES_FILE} -f ${UI_CONFIG_VALUES_FILE} --wait
helm install scan oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-scan -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/scan-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
helm install validator oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-validator -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/validator-values.yaml -f splice-node/examples/sv-helm/sv-validator-values.yaml -f ${UI_CONFIG_VALUES_FILE} --wait
```

Install the INFO app, which is used to provide information about the SV node and its configuration:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install info oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-info -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/info-values.yaml
```

Once everything is running, you should be able to inspect the state of the cluster and observe pods running in the new namespace. A typical query might look as follows:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
$ kubectl get pods -n sv
NAME                                         READY   STATUS    RESTARTS      AGE
apps-pg-0                                    2/2     Running   0             14m
ans-web-ui-5cf76bfc98-bh6tw                  2/2     Running   0             10m
global-domain-0-cometbft-c584c9468-9r2v5     2/2     Running   2 (14m ago)   14m
global-domain-0-mediator-7bfb5f6b6d-ts5zp    2/2     Running   0             13m
global-domain-0-sequencer-6c85d98bb6-887c7   2/2     Running   0             13m
info-9fb7bc859-27226                         2/2     Running   0             10m
mediator-pg-0                                2/2     Running   0             14m
participant-0-57579c64ff-wmzk5               2/2     Running   0             14m
participant-pg-0                             2/2     Running   0             14m
scan-app-b8456cc64-stjm2                     2/2     Running   0             10m
scan-web-ui-7c6b5b59dc-fjxjg                 2/2     Running   0             10m
sequencer-pg-0                               2/2     Running   0             14m
sv-app-7f4b6f468c-sj7ch                      2/2     Running   0             13m
sv-web-ui-67bfbdfc77-wwvp9                   2/2     Running   0             13m
validator-app-667445fdfc-rcztx               2/2     Running   0             10m
wallet-web-ui-648f86f9f9-lffz5               2/2     Running   0             10m
```

Note also that `Pod` restarts may happen during bringup, particularly if all helm charts are deployed at the same time. The `splice-sv-node` cannot start until `participant` is running and `participant` cannot start until `postgres` is running.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create ns cluster-ingress
```

Ensure that there is a cert-manager certificate available in a secret named `cn-net-tls`. An example of a suitable certificate definition:

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
   name: cn-certificate
   namespace: cluster-ingress
spec:
    dnsNames:
    - '*.sv.YOUR_HOSTNAME'
    issuerRef:
        name: letsencrypt-production
    secretName: cn-net-tls
```

Create a file named `istio-gateway-values.yaml` with the following content (Tip: on GCP you can get the cluster IP from `gcloud compute addresses list`):

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
service:
    loadBalancerIP: "YOUR_CLUSTER_IP"
    loadBalancerSourceRanges:
        - "35.194.81.56/32"
        - "35.198.147.95/32"
        - "35.189.40.124/32"
        - "34.132.91.75/32"
```

And install it to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install istio-ingress istio/gateway -n cluster-ingress -f istio-gateway-values.yaml
```

Create Istio Gateway resources in the `cluster-ingress` namespace. Save the following to a file named `gateways.yaml`, with the following modifications:

* Replace `YOUR_HOSTNAME` with the actual hostname of your SV node
* The second gateway (cn-apps-gateway) exposes ports for three migration IDs (0, 1, and 2) for the CometBFT apps of the SV node. If a higher migration ID is reached, expand that list using the same pattern.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-http-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: cn-net-tls # name of the secret created above
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
  - port:
      number: 80
      name: http
      protocol: HTTP
    tls:
      httpsRedirect: true
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-apps-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 26016
      name: cometbft-0-1-6-gw
      protocol: TCP
    hosts:
      # We cannot really distinguish TCP traffic by hostname, so configuring to "*" to be explicit about that
      - "*"
  - port:
      number: 26116
      name: cometbft-1-1-6-gw
      protocol: TCP
    hosts:
      - "*"
  - port:
      number: 26216
      name: cometbft-2-1-6-gw
      protocol: TCP
    hosts:
      - "*"
```

And apply them to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl apply -f gateways.yaml -n cluster-ingress
```

The http gateway terminates tls using the secret that you configured above, and exposes raw http traffic in its outbound port 443. Istio VirtualServices can now be created to route traffic from there to the required pods within the cluster. A reference Helm chart is provided for that, which can be installed after

1. replacing `YOUR_HOSTNAME` in `splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml` and
2. setting `nameServiceDomain` in the same file to `"cns"`

using:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install cluster-ingress-sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cluster-ingress-runbook -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml
```

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create ns cluster-ingress
```

Ensure that there is a cert-manager certificate available in a secret named `cn-net-tls`. An example of a suitable certificate definition:

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
   name: cn-certificate
   namespace: cluster-ingress
spec:
    dnsNames:
    - '*.sv.YOUR_HOSTNAME'
    issuerRef:
        name: letsencrypt-production
    secretName: cn-net-tls
```

Create a file named `istio-gateway-values.yaml` with the following content (Tip: on GCP you can get the cluster IP from `gcloud compute addresses list`):

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
service:
    loadBalancerIP: "YOUR_CLUSTER_IP"
    loadBalancerSourceRanges:
        - "35.194.81.56/32"
        - "35.198.147.95/32"
        - "35.189.40.124/32"
        - "34.132.91.75/32"
```

And install it to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install istio-ingress istio/gateway -n cluster-ingress -f istio-gateway-values.yaml
```

Create Istio Gateway resources in the `cluster-ingress` namespace. Save the following to a file named `gateways.yaml`, with the following modifications:

* Replace `YOUR_HOSTNAME` with the actual hostname of your SV node
* The second gateway (cn-apps-gateway) exposes ports for three migration IDs (0, 1, and 2) for the CometBFT apps of the SV node. If a higher migration ID is reached, expand that list using the same pattern.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-http-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: cn-net-tls # name of the secret created above
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
  - port:
      number: 80
      name: http
      protocol: HTTP
    tls:
      httpsRedirect: true
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-apps-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 26016
      name: cometbft-0-1-6-gw
      protocol: TCP
    hosts:
      # We cannot really distinguish TCP traffic by hostname, so configuring to "*" to be explicit about that
      - "*"
  - port:
      number: 26116
      name: cometbft-1-1-6-gw
      protocol: TCP
    hosts:
      - "*"
  - port:
      number: 26216
      name: cometbft-2-1-6-gw
      protocol: TCP
    hosts:
      - "*"
```

And apply them to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl apply -f gateways.yaml -n cluster-ingress
```

The http gateway terminates tls using the secret that you configured above, and exposes raw http traffic in its outbound port 443. Istio VirtualServices can now be created to route traffic from there to the required pods within the cluster. A reference Helm chart is provided for that, which can be installed after

1. replacing `YOUR_HOSTNAME` in `splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml` and
2. setting `nameServiceDomain` in the same file to `"cns"`

using:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install cluster-ingress-sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cluster-ingress-runbook -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml
```

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl create ns cluster-ingress
```

Ensure that there is a cert-manager certificate available in a secret named `cn-net-tls`. An example of a suitable certificate definition:

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
   name: cn-certificate
   namespace: cluster-ingress
spec:
    dnsNames:
    - '*.sv.YOUR_HOSTNAME'
    issuerRef:
        name: letsencrypt-production
    secretName: cn-net-tls
```

Create a file named `istio-gateway-values.yaml` with the following content (Tip: on GCP you can get the cluster IP from `gcloud compute addresses list`):

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
service:
    loadBalancerIP: "YOUR_CLUSTER_IP"
    loadBalancerSourceRanges:
        - "35.194.81.56/32"
        - "35.198.147.95/32"
        - "35.189.40.124/32"
        - "34.132.91.75/32"
```

And install it to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install istio-ingress istio/gateway -n cluster-ingress -f istio-gateway-values.yaml
```

Create Istio Gateway resources in the `cluster-ingress` namespace. Save the following to a file named `gateways.yaml`, with the following modifications:

* Replace `YOUR_HOSTNAME` with the actual hostname of your SV node
* The second gateway (cn-apps-gateway) exposes ports for three migration IDs (0, 1, and 2) for the CometBFT apps of the SV node. If a higher migration ID is reached, expand that list using the same pattern.

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-http-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: cn-net-tls # name of the secret created above
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
  - port:
      number: 80
      name: http
      protocol: HTTP
    tls:
      httpsRedirect: true
    hosts:
    - "*.YOUR_HOSTNAME"
    - "YOUR_HOSTNAME"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cn-apps-gateway
  namespace: cluster-ingress
spec:
  selector:
    app: istio-ingress
    istio: ingress
  servers:
  - port:
      number: 26016
      name: cometbft-0-1-6-gw
      protocol: TCP
    hosts:
      # We cannot really distinguish TCP traffic by hostname, so configuring to "*" to be explicit about that
      - "*"
  - port:
      number: 26116
      name: cometbft-1-1-6-gw
      protocol: TCP
    hosts:
      - "*"
  - port:
      number: 26216
      name: cometbft-2-1-6-gw
      protocol: TCP
    hosts:
      - "*"
```

And apply them to your cluster:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
kubectl apply -f gateways.yaml -n cluster-ingress
```

The http gateway terminates tls using the secret that you configured above, and exposes raw http traffic in its outbound port 443. Istio VirtualServices can now be created to route traffic from there to the required pods within the cluster. A reference Helm chart is provided for that, which can be installed after

1. replacing `YOUR_HOSTNAME` in `splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml` and
2. setting `nameServiceDomain` in the same file to `"cns"`

using:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
helm install cluster-ingress-sv oci://ghcr.io/digital-asset/decentralized-canton-sync/helm/splice-cluster-ingress-runbook -n sv --version ${CHART_VERSION} -f splice-node/examples/sv-helm/sv-cluster-ingress-values.yaml
```