Alright, this is something I've been noodling on for a while and finally got into a state I'm happy to share. Like many of you, we manage a ton of internal services and staging environments, and manually adding each new deployment as a Twingate resource was becoming a real chore and a source of human error. Our DevOps team would deploy, but then the product team couldn't access it because someone forgot to update Twingate.
So, I built a script that hooks into our CI/CD pipeline (GitLab, but the concept is portable) to automatically create Twingate resources based on git tags and environment variables. The goal was zero-touch provisioning for our standard deployment patterns.
Here’s the core idea and workflow:
* We use a specific tag naming convention for deployments (e.g., `svc-payments-v1.2.3`, `env-staging-feature-branch`).
* The script parses these tags to determine the service name, environment, and purpose.
* It then uses the Twingate Terraform Provider (via the `twingate` CLI) to idempotently create:
* A new Remote Network (if one for that environment doesn't exist).
* A new Connector in that network (or reuses an existing one).
* The actual Resource, defining the protocol, port, and address (usually a dynamic K8s service name or load balancer).
* It also tags the resources in Twingate with the service and environment, which is great for our internal auditing and cleanup scripts.
The real win has been consistency and speed. Every new staging environment for a feature branch is now automatically accessible to the right people without a single ticket or Slack message. It’s also been a boon for cleaning up; we have a companion cron job that looks for resources tagged with old feature branches and decommissions them.
I'm curious if others have tackled similar automation. I've seen snippets for static resource creation, but not so much for dynamic, tag-driven workflows. If there's interest, I can share the more detailed logic around parsing and error handling—it’s the part that took the most iteration to get robust.
What are your automation pain points with Twingate? Have you integrated it deeper into your infra-as-code or deployment pipelines? I'd love to compare notes and see if we can collectively build even better patterns.
— Charlotte
That's a solid approach to automating a tedious process. I've seen similar patterns work well, but the devil is in the state management. I'm curious how you're handling the lifecycle - specifically, resource cleanup for ephemeral environments like feature branches.
When a deployment is torn down, does your script also invoke a `terraform destroy` or `twingate resource delete` based on the same tag, or are you relying on a separate cleanup job? Without that, you risk accumulating stale resources and connectors, which can become a security concern over time. A potential refinement is to have the script check for a tag prefix like `destroy-` to trigger removal, making the workflow fully bidirectional.