Skip to content
Notifications
Clear all

Has anyone tried automating Twingate connector deployments with Terraform?

2 Posts
2 Users
0 Reactions
4 Views
(@ellaq)
Estimable Member
Joined: 1 week ago
Posts: 107
Topic starter   [#12931]

Hey everyone! 👋 I've been deep in the weeds with Twingate for the last few months, rolling it out across our dev and sales teams to replace our old VPN setup. The zero-trust model is fantastic for security, but as a RevOps person who lives in automation, the manual process of deploying new connectors for each environment has been... a bit of a pain point.

We're using a multi-account cloud setup, and every time we spin up a new staging or demo environment, I find myself clicking through the admin console to configure a new connector, its routes, and resource definitions. It feels like the exact kind of repetitive task that should be codified. Given my background with infrastructure-as-code for our CRM and data pipelines, Terraform seems like the perfect fit to bring some order here.

So, my big question: **Has anyone actually automated Twingate connector deployments with Terraform?** I've been poking around and I see Twingate has a Terraform provider listed on their site, but I'm really curious about practical, real-world experiences.

Specifically, I'd love to know:
* How mature and reliable is the provider? Are the resources you need (connectors, resources, groups) all available?
* What does your workflow look like? Do you store the connector tokens securely in something like Vault or AWS Secrets Manager and then pull them into your Terraform vars?
* Have you managed to tie this into a full CI/CD pipeline? For example, having a GitHub Action automatically provision a Twingate connector when a new cloud account is created via Terraform?
* Any gotchas or pitfalls? I'm particularly worried about state managementβ€”if someone makes a manual change in the Twingate console, does it cause a big drift headache?

I'm imagining a future where our infrastructure code defines not just the network, but also the secure access layer right alongside it. That would be a huge win for consistency and audit trails. If you've tried this, walked this path, or even decided it wasn't worth it yet, I'm all ears! I'm hoping to start a proof-of-concept soon and would love to learn from your experiences before I dive in.

TIL


Pipeline is king.


   
Quote
(@data_analytics_rover)
Reputable Member
Joined: 4 months ago
Posts: 150
 

The Terraform provider is functional for core resources. I've managed about thirty connectors through it over the last year for a similar multi-account setup.

You'll find the `twingate_connector` and `twingate_remote_network` resources are stable. The `twingate_resource` and group assignments work, but I had to be explicit with dependencies in my module to avoid race conditions during apply.

The main gap was around connector tokens. The provider can create them, but you'll need a separate process to securely inject the token into your connector's runtime environment (like a Kubernetes secret or a Parameter Store value). That piece isn't covered by the provider itself.

How are you planning to handle the token lifecycle? That's where most of my custom scripting ended up.



   
ReplyQuote