Hi all - I’m the CTO & cofounder of Twingate. Since we released Twingate a few months ago, we’ve been hard at work extending the product and are excited to announce the release of a Twingate client for Linux (with support for major distros including Ubuntu, CentOS, and Fedora).
We specifically built Twingate to make developers’ lives easier, and wanted to explain how we’ve designed it to tackle a lot of pain points that devs have with VPNs and other remote access products. Twingate is deployed as a network overlay on top of your existing network so you can enable remote access to any protected host or destination without having to re-architect your network. Just deploy our connectors inside any number of existing networks, define access policies by destination address, and install our client apps on your device for access. No firewall changes, routing rules, proxy configurations, etc. Access your private resources using the local IP or private DNS you’ve always used and we handle all the routing and local DNS resolution automatically.
We’ve designed Twingate with developers in mind and built a number of features to make remote access easy for development teams. Twingate provides a single interface for developers to access multiple environments, supports any protocol and app out of the box, and intelligently segregates and routes traffic via the most direct path to minimize latency.
You can try it out for free and we’d love to hear your feedback!
From an European perspective: You are asking for a lot of trust. Meanwhile, you violate any trust by not complying with GDPR. That's an honest question: why should I grant your closed source application access to my network, if you aren't even respecting my privacy (rights) on a fundamental level?
Hi jsuki - I work at Twingate and we take privacy really seriously, but compliance with GDPR doesn’t require companies to open source their products. We also actually don’t collect much personal data - mainly the names and emails of users (not even passwords since we rely on identity providers to authenticate users). Also, any data sent between client devices and private network resources secured with Twingate is encrypted end-to-end so there’s no way for us to inspect it.
You do ask a valid question about why you should trust us, though. As a security company, we can’t build a business if we don’t have the trust of our customers. Our product undergoes security reviews by an external party and we are in the process of getting a third party security audit done, so you won’t just have to take our word for it.
Hi benmccann,
I'm Eran, one of the engineering leads on Twingate.
I'm a not Tailscale expert but as far as I understand, the biggest difference between us and Tailscale is that we allow our customers and users to continue using existing private DNS and IP addresses.
This means that users can continue accessing internal resources exactly as they did before.
From an infrastructure standpoint, as you point out with the Docker container, Twingate is also incredibly easy to deploy.
No need to install Twingate on every single destination service, you can just install our connectors on the relevant network segment and we'll take care of routing traffic to the appropriate destination.
Making the product as easy to use and deploy is the primary guiding principle for our product, and we're getting great customer feedback around that.
Haven't tried it myself, but while it seems Gravitational is focused on SSH and Kubernetes use-cases, we've built Twingate to support a wide range of protocols and use-cases across the organization.
We use Kubernetes internally and we use Twingate to securely access internal tools (Like ELK, Grafana, as well as SSH) without having to expose public IPs or worry whether they get hacked or DDoSed.
Before Twingate we had to spend a lot of effort to make such tools accessible securely.
The biggest difference is that Tailscale people can get into your machines whenever they want since they generate and distribute the keys and endpoints and you have to trust them more than your mom that they won't hurt you.
12 comments
[ 3.4 ms ] story [ 37.7 ms ] threadWe specifically built Twingate to make developers’ lives easier, and wanted to explain how we’ve designed it to tackle a lot of pain points that devs have with VPNs and other remote access products. Twingate is deployed as a network overlay on top of your existing network so you can enable remote access to any protected host or destination without having to re-architect your network. Just deploy our connectors inside any number of existing networks, define access policies by destination address, and install our client apps on your device for access. No firewall changes, routing rules, proxy configurations, etc. Access your private resources using the local IP or private DNS you’ve always used and we handle all the routing and local DNS resolution automatically.
We’ve designed Twingate with developers in mind and built a number of features to make remote access easy for development teams. Twingate provides a single interface for developers to access multiple environments, supports any protocol and app out of the box, and intelligently segregates and routes traffic via the most direct path to minimize latency.
You can try it out for free and we’d love to hear your feedback!
We also have a extensive documentation on how Twingate works here if you’d like to take a peek under the hood: https://docs.twingate.com/docs/how-twingate-works
You do ask a valid question about why you should trust us, though. As a security company, we can’t build a business if we don’t have the trust of our customers. Our product undergoes security reviews by an external party and we are in the process of getting a third party security audit done, so you won’t just have to take our word for it.
Good, then complying with GDPR isn't much work. So why don't you?
I'm a not Tailscale expert but as far as I understand, the biggest difference between us and Tailscale is that we allow our customers and users to continue using existing private DNS and IP addresses. This means that users can continue accessing internal resources exactly as they did before. From an infrastructure standpoint, as you point out with the Docker container, Twingate is also incredibly easy to deploy. No need to install Twingate on every single destination service, you can just install our connectors on the relevant network segment and we'll take care of routing traffic to the appropriate destination. Making the product as easy to use and deploy is the primary guiding principle for our product, and we're getting great customer feedback around that.
Eran.
We use Kubernetes internally and we use Twingate to securely access internal tools (Like ELK, Grafana, as well as SSH) without having to expose public IPs or worry whether they get hacked or DDoSed. Before Twingate we had to spend a lot of effort to make such tools accessible securely.