# How to Deploy a Connector on GCP

## Overview

There are several options available for deploying Connectors on Google Cloud Platform depending on your particular environment and needs.

### Check your subnet configuration

The subnet you deploy a Connector in requires outbound Internet access, both to download the Connector container image and to connect to Twingate. Check our [Best Practices for Connectors guide](/content/docs/connector-best-practices#network-requirements/index.html) for more information.

### Cloud NAT port allocation

If your Connector VM uses [Cloud NAT](https://cloud.google.com/nat/docs/overview) for outbound internet access and shares the NAT gateway with other services such as analytics or batch workloads that make high volumes of parallel outbound connections, review the `min_ports_per_vm` setting on your NAT gateway. GCP’s default is tuned for large fleets and may be insufficient in smaller deployments. See [Tune NAT configuration](https://cloud.google.com/nat/docs/tune-nat-configuration) in the GCP docs for details.

[Peer-to-peer connections](/content/docs/peer-to-peer-communication-in-twingate/index.html) help you to provide a better experience for your users and to stay within the [Fair Use Policy](/content/terms/sa/index.html) for bandwidth consumption. Learn how to [support peer-to-peer connections](/content/docs/troubleshooting-p2p/index.html).

## Compute Engine Deployment

If you are deploying a custom virtual machine, you can follow the general [Linux](/content/docs/connectors-on-linux/index.html) Connector deployment instructions for full details.

In summary:

- Docker-based deployment is compatible with any 64-bit Linux distribution that Docker supports.
- The Connector `systemd` service is currently supported on [Ubuntu, Fedora, Debian, and CentOS](/content/docs/connectors-on-linux#supported-distributions/index.html).

Please see our [Connector Best Practices](/content/docs/connector-best-practices/index.html) overview for general recommendations as well as hardware recommendations for Google Cloud.

## Automated Compute Engine Deployment

We offer an automated method of deploying a Compute Engine instance with the Connector pre-installed. Use the steps below to create and configure a Compute Engine instance.

- Log in to your Twingate Admin Console, click on Remote Networks then on the Remote Network on which you want to deploy a Connector. From there, scroll down and click on the Add Connector button on the left-hand side of the screen
- Click on the new Connector that was created. On the deployment page click the Google Cloud option at the top of the screen  
  
- Scroll down to step 2 and click the button to generate tokens. It will have you re-authenticate and then bring you back to this page  
  
- Scroll down to step 3 and fill out the required information about your Google Cloud environment, as well as enable and configure the optional features  
  
- Scroll down to step 5 and copy the command to launch the Connector. Run it in the Google Cloud CLI

## Google Kubernetes Engine (GKE) Deployment

Connectors can also be deployed on a GKE cluster using the [official Twingate Helm chart](https://github.com/Twingate/helm-charts). If you intend use Twingate for K8s, you may also want to look at our [Kubernetes Best Practices Guide](/content/docs/k8s-cluster-access/index.html).

## Infrastructure as Code Deployment

[Deployment automation](/content/docs/deployment-semi-automation/index.html) is available using [Terraform](/content/docs/terraform-gcp/index.html), [Pulumi](/content/docs/pulumi-gcp/index.html), or the [Twingate API](/content/docs/api-overview/index.html).

Access and refresh tokens, which are required for Connector deployment, are specific to an individual Connector and cannot be shared between multiple Connectors.

## Updating the Connector

Connectors running on GCP run as a `systemd` service. Updates can be done manually by using the Linux package manager, or automatically by setting up a scheduled task to check for updates. We recommend staggering updates across multiple Connectors to avoid downtime. For more details check our [Systemd Connector Update Guide](/content/docs/systemd-service/index.html).

Last updated 5 months ago.