Skip to main content

Google Cloud Marketplace Deployment & Post Deployment Script Manual

Before We Start

Here are a few quick pointers to keep in mind while deploying the Polygon Edge network from Google Cloud Marketplace.

  • This product is offered in the form of four node architecture. Four nodes spanning across four availability zones spanning two or more regions give higher tolerance in case of any issues with the either availability zone or region.
  • The customer can launch:
    • all four nodes in a single region spanning multiple availability zones, or
    • two nodes in one region and another two nodes in another region, or
    • each node in one availability zone belonging to one region thus spanning across all four regions.
  • There is a bootstrap node that gets provisioned as part of the deployment process, performs its job, and gets terminated. The rest of the four nodes viz. Node1, Node2, Node3, and Node4 serve the traffic.
  • Five service accounts will be created and they get attached to the five nodes. When you run the deployment for the first time from a marketplace in your GCP project, it is obvious that you won’t be having the service accounts with the necessary roles.
  • You are supposed to choose the Create a New Service Account option for every node and give the service account a name, ID, and description of your choice. However, to ease the relationship between the node and the service account, we strongly recommend using the node names in the service account. Ex: bootstrap-node-sa, node1-sa, node2-sa etc.
  • The bootstrap node service account has more privileges than other node service accounts. Due to that reason, once the application bootstrapping process is done, the node gets terminated automatically to avoid its misuse.
  • You are allowed to choose the VPC in which you need to run the nodes. However, make sure that you are selecting the same VPC for all the nodes. In case you choose different VPCs for different nodes then you need to make sure that you have routing established between the VPCs and their respective subnets. Otherwise, it would lead to a breakage of communication between the nodes.
  • By default, the Deployment Manager form selects Default VPC. If you decide to go with a custom VPC, then it is your responsibility to choose the custom VPC explicitly. Based on the node region selected, automatic subnet selection happens from the VPC. In case the region selected for the node doesn’t have a subnet, then it remains blank. So you have to either change the node region or create a new subnet in that region.
  • By default, all nodes are allowed to get an Ephemeral Public IP address. If you choose not to have a public IP address then it is your responsibility to set the Public IP address to NONE.
  • To avoid unauthorized entries into your blockchain nodes, it is strongly recommended that you go without Public IPs for the nodes. This product also provides a post-deployment script that provisions a Load Balancer which makes the necessity of the public IP obsolete.
  • If the source IP ranges for ports 8545 and 1478 are left blank, then the deployment automatically takes If you wish to go with public IPs to the nodes, it is recommended to give specific source IP ranges for port 8545 so that you will have better security. Port 1478 is for communication between the four nodes. It is recommended to use the CIDR ranges of the subnets in which the nodes are going to be provisioned.
  • The GCS bucket is used only to share a few files for bootstrapping the Edge application. Once the application is up and running then it is no more required. Please note that it doesn’t contain any sensitive information related to the blockchain.
  • In order to have a successful deployment of the application, a unique GCS name has to be passed to the deployment form. So, you must add your Project ID as a suffix to your bucket name. Bucket names must follow Google GCS naming guidelines. Caps and Special Characters (except - and _ ) are not allowed.
  • The genesis file can be generated by inputting some initial premine addresses and balances in CSV format e.g. address1:balance,address2:balance. A maximum of 200 premine addresses are allowed due to the deployment form field limitations of Google Cloud Marketplace.
  • With 150 premine addresses, It takes ~5 mins for the entire deployment process to complete and get the application up and running. It would go to a maximum of ~6 mins if you have given a total of 200 premine addresses.

Post Deployment Script Manual for Polygon Edge


  • Successful completion of Polygon Edge VM’s deployment from the marketplace.
  • For a production-grade setup, a public DNS domain with privileges to modify the nameservers is required.
  • The operator who executes the post-deployment script must have the following roles - roles/compute.admin, roles/dns.admin. Basic roles such as Editor or Owner roles can also be given.
  • Cloud DNS API should be enabled.
  • gcloud CLI installed with the latest version. Access Google Cloud Docs for instructions.
  • gcloud CLI configured under the same project where the Polygon Edge product has been deployed. Access Google Cloud configuration docs for configuration steps.


The below components get provisioned when the post-deployment script gets executed successfully:

  • SSL Certificate (If you don’t have one)
  • Network Endpoint Groups (NEG’s)
  • Global Load Balancer
  • Managed Zone (if you don’t have one)

SSL Certificate

  • Users can use an existing certificate created within GCP by giving the certificate name when the post deployment script asks.
  • Users might have a certificate that was created using third-party providers like Letsencrypt or Zerossl etc. Users can pass the certificate .pem file and private key files absolute paths which were saved on the local file system where the script is getting executed. The script then creates a certificate in the GCP using those files. The created certificate will then be associated with the load balancer and makes the requests secure.
  • Users can create a new certificate within GCP and this can be done by letting the script know that the user doesn’t have an existing certificate or doesn’t have a certificate .pem and private key files while running the script.

Managed Zone

The script is designed to either use an existing Managed Zone or create a new Managed Zone in the project.

  • Users can create a new Managed Zone by letting the script know that the user doesn’t have an existing zone created for the domain.
  • Users can also input the name of the existing managed zone to the script.

Script Execution

$ bash

  • The script code is available for download here.

  • The script is interactive with a couple of questions. The script might take around 4 minutes to complete.

  • The below screenshot shows how the script behaves when a user gives invalid inputs (or) input the script that the user doesn’t have a domain name.

  • The below screenshot shows the creation of a new SSL certificate.

  • The below screenshot shows the creation of a new SSL certificate by importing the user-provided certificate .pem and private key files.

  • The below screenshot shows how an existing SSL certificate can be inputted into the script.

  • The below screenshots show the Load Balancer creation process.

  • The below screenshot shows the creation of a new Managed Zone.

  • The below screenshots show the created Managed Zone and its name server details.

  • The name servers of the created Managed Zone

  • The below screenshot shows the domain name servers were updated with managed zone name servers.


It is your responsibility to update the managed zone name servers' details in your domain registrar Nameservers section. If you chose to create a new SSL certificate in GCP then the certificate won’t be provisioned successfully for the domain until the Managed Zone Nameservers are updated in your Domain Registrar Nameservers section. The certificate issuing process and domain name propagation might take a few hours to a maximum of 3 days. Although it gets completed in a couple of hours in most cases.

Destroying the created resources

Created resources are categorized into two types:

  • Resources created from Marketplace deployment (the VM’s in this case)
  • Resources created by executing the post-deployment script (LB ,SSL, and DNS record sets)

Destroying the resources should happen in order. We have described the flow of deletion in the below steps.

Delete resources created using the Post-deployment script

  • The below screenshot shows the options that display when Destroy is selected.

  • The below screenshot shows the destroying process when LoadBalancer is selected.

  • The below screenshot shows the destroying process when SSL Certificate is selected.

  • The below screenshot shows the destroying process when DNS Record Set is selected.

  • The below screenshot shows the destroying process when DNS Record Set & Managed Zone is selected.

  • The below screenshots show the destroying process when All of the above options are selected.

Delete resources created from the Marketplace

The below screenshot shows how those resources can be deleted from the Deployment manager.

Deleting secrets created in the Secrets Manager

Each Node will have two secrets viz. Network Key and Validator Key. So for four nodes, a total of eight secrets need to be deleted. The below screenshot shows the deletion of secrets from the secrets manager console.

Delete the temporary bucket storing the Node details & Genesis file

In order to delete a bucket, first it should be made empty, so delete the objects first and then delete the bucket. The below two screenshots shows the objects deletion and bucket deletion process.

Remove access to the Service Accounts and Delete

The below two screenshots show the steps to remove roles from a service account and then delete the service accounts.