Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deployment

Deploy the GCP Brain VM using the Vectra template and `gcloud infra-manager`, then connect and complete provisioning.

Deploying the Brain Image

  • You will need to download the template file from Vectra that was identified in the welcome email. Save it to a locally accessible directory from where you will run the gcloud deployment command.

    • <VERSION>_example.tf – Save a new copy of this and edit it to customize the deployment for your needs.

      • This template contains instructions and syntax for the deployment command.

  • Do NOT change the source argument. Only use the source specified in the <VERSION>_example.tf file.

  • Vectra recommends that you do not have any other files in the directory from which you run the deployment command. The gcloud command could run more slowly or error if there are other terraform files in the directory.

  • Below is a sample edited <VERSION>_example.tf file.

    • In this case, the file was called 9.7_example.tf.

####################################################################################
# This configuration deploys resources necessary for the Vectra Brain product.     #
#                                                                                  #
# This template can be deployed with the `gcloud` commandline tool.                #
# Please save this file into an empty directory of your choosing.                  #
# Before deploying the template, update the arguments in this file to              #
# the desired values. The comment above each argument should explain the argument. #
#                                                                                  #
# Then, from within the directory, run: (replacing the placeholders in <>)         #
# $ gcloud infra-manager deployments apply \                                       #
#  --service-account <your_service_account> \                                      #
#  --project <your_project> \                                                      #
#  projects/<your_project>/locations/<your_region>/deployments/<deployment_name> \ #
#  --local-source=./                                                               #
#                                                                                  #
# You may also use Terraform on its own if you are familiar with using Terraform.  #
#                                                                                  #
####################################################################################
 
# the label of the module ("my_test_brain") is only used internally by terraform,
# so you can set it to anything
module "my_test_brain" {
  source = "https://cognito-public-deployment-tools.s3.us-west-2.amazonaws.com/GCPBrain/9.7.zip"
  # Name of the resources to be created (will be appended to; e.g. the name `vectra-brain` will create `vectra-brain-vm` and `vectra-brain-os`)
  name = "brain-resources"
  # Token for provisioning with Vectra, UUID format
  provision-token = "6f9defc5-0db2-4854-92fe-5bb4dfc7b1f8"
  # SSH public key for vectra user (format: ssh-rsa XXXX)
  ssh-key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAtruncatedforvisibilityreasons"
  # Project in which to deploy (project ID)
  project = "example-dev"
  # Service account name for VM (only 'name' in <name>@<project>.iam.gserviceaccount.com)
  service-account = "tme-test"
  # Region in which to deploy
  region = "us-east4"
  # Zone in which to deploy (actual zone, not just region)
  zone = "us-east4-a"
  # Size of brain VM, must be one of n2-highmem-16, n2-highmem-32, n2-highmem-64, n2-highmem-96
  size = "n2-highmem-96"
  # Base image provided by Vectra
  image = "projects/vectra-shared-images/global/images/vectra-gcp-brain-9-7"
  # Management subnetwork for VM (subnetwork selflink, such as projects/PROJ/regions/REG/subnetworks/SUBNET)
  subnetwork = "projects/example-dev/regions/us-east4/subnetworks/mgt"
}

  • After editing the <VERSION>_example.tf file, you are now ready to deploy the Brain.

  • Perform the deployment using the gcloud infra-manager deployments apply command. Be sure to specify the service account created for Infrastructure Manager, not the one created for the Brain to use.

As of 2026-06-25, the gcloud tool always uploads the contents of the directory containing the Terraform file to a bucket in the US region when using the --local-source option, regardless of the location you choose with the --location option. If you do not want to create resources in the US region, you will need to create a bucket yourself, manually upload the contents of the Terraform directory, and use --gcs-source instead of --local-source.

  • Please see below for an example:

  • If the deployment fails, you can view the logs by going to Infrastructure Manager in the Google Cloud console, and clicking on the deployment that failed:

  • For example, this deployment failed because the image was not yet shared with the example customer:

When deploying the Brain image, you may see a warning about the disk size being different than the image size. This is expected and can be ignored. The Brain will resize the partition upon boot.

  • If you have failed deployments for any reason, you can simply delete them by name as in this example:

  • You can list deployments as follows:

    • gcloud infra-manager deployments list -–project --location

  • To see resources created with a deployment, you can click on the Resources tab on the deployment page in the GCP console.

Connecting to the Brain

The Brain will automatically power on after the gcloud infra-manager deployments apply command has completed. The Brain is assigned an IP in the subnet that you chose for the management interface earlier. If you already have private connectivity in place to GCP from your environment, you can simply browse to this IP over HTTPS to see the status pages as the Brain progress through the rest of its initialization process.

If you require a public IP for your Brain, this can be configured by adding an external IP to your Brain VM and then opening up GCP firewall rules to allow connectivity from the internet. Please keep in mind that it is not generally advisable to expose the Brain to the Internet directly. If you do so, you should limit what IPs or ranges can connect to any public IP that you create.

Per the earlier firewall requirements section, please ensure that your inbound firewall rules allow HTTPS (TCP/443) and SSH (TCP/22) inbound from where you will connect to the Brain from. Also ensure that your Brain VM can reach the Vectra Cloud to complete provisioning through either Cloud NAT in GCP or if you assign an external IP address to the VM.

Completing the Brain Deployment

Once you bypass a warning for the self-signed certificate that is created by default on the Brain, you will be presented with information relaying the status of the Brain’s progress as it continues through the deployment process. It will proceed through the following stages:

  • Authenticating and verifying the file system of the virtual Brain appliance.

  • Rebooting.

  • Decryption of the file system.

  • Connecting to the Vectra provisioning server and provisioning.

Example screenshots:

If a proxy is required to access Vectra in your GCP environment, this can be configured during this time by clicking on the “Set Proxy Configuration” link on any of these status screens.

  • Please note: This proxy configuration screen is only used to communicate with Vectra’s provisioning server and must utilize an HTTPS proxy. HTTP only proxies are not supported for this use. Other proxy configuration in the main Vectra UI (Data Sources > Network > Brain Setup > Proxy) after deployment does accept HTTP proxies and is used by non-provisioning related services and integrations.

  • Please note: If you are doing a Respond UX deployment and require a proxy for non-provisioning related services and integrations (this includes linking to Vectra’s cloud for use with the Respond UX), you should configure that proxy at the CLI of your Brain AFTER you progress through this initial configuration and get to the “Success!” message at the end of this section. Please see the Respond UX Deployment Guide in the Deployment > Proxy Support section for more detail.

Once complete, you will see the following:

Clicking on the blue Login button will take you to the login page of the Brain (Quadrant UX).

If you are doing a Respond UX deployment, you should NOT login to the local GUI (which is the Quadrant UX) before linking with Vectra.

Once linked with Vectra per the Respond UX Deployment Guide, your Brain will no longer show a Quadrant UX login screen when you browse to its IP or hostname and will instead show a page that instructs you to login to the Respond UX in Vectra’s cloud or a status page.

  • Please note that that the Brain may require several updates to become current with Vectra’s latest generally available Brain version.

    • Please do not power off the Brain during the initial GCP deployment prior to login or during the updating process as the Brain becomes current.

    • If powered off during initial deployment the Brain may become unresponsive and require redeployment.

    • During this time the UI may become unresponsive, or you may be disconnected but it is safe to configure platform settings.

    • Periodically, the Brain image is updated and when deploying a new Brain, always check with Vectra for the latest base image available for your deployment.

Default login credentials

If you are doing a Respond UX deployment, you should NOT login to the local GUI (which is the Quadrant UX) before linking with Vectra.

The default credentials to login to the Vectra Brain GUI (Quadrant UX only) over HTTPs in GCP are

  • Username: admin

  • Password: Virtual Machine Name (typically the deployment name with -vm after it)

Logging in at the CLI can be done via SSH using the private key corresponding to the public key that was assigned to this stack and the vectra username. Login to the CLI is supported for both Quadrant UX and Respond UX deployment types.

Please ensure firewall rules are updated to allow CLI and GUI access as per earlier guidance.

PreviousFirewall requirementsNextPost deployment configuration

Last updated

Was this helpful?