Simplify your developer workflow and work faster

• VPNs are not always on and developers need to add one extra step to the login process.
• Due to IP routing limitations with VPNs, developers can't connect to two VPNs at the same time to avoid subnet collisions.
• VPNs route all traffic through a centralized location/server so scaling VPN hardware is a burden.  It's either expensive with hosted solutions or time-consuming and a possible security vector for having unpatched VPN services and agents.
• Developers have to talk to IT or DevOps to add IP addresses to the Access Control List.  Alternatively, some organizations allow developers to update the Allowed/Whitelist on their own which reduces the number of employees in the process but could lead to security threats.
• VPNs can be set up in a “split-tunnel” where private IP addresses route through the VPN but public IP addresses route through your own internet connection.  This means that your public IP address changes when you are at a coffee shop even when on a VPN.  It is also a false sense of security because you believe you are using the VPN 100% when in fact you are not.
• Some MySQL databases only have a public endpoint such as an AWS RDS MySQL setup for public access.  VPNs can't solve this problem.
• If you need to grant public access to some users, you will still need to have an access list. Now you are managing a VPN and an Access List.

" I like the idea that when using Remote.It, not all resources are up at the same time.  I have them prepped, so I can connect to them, but they're not actually connected.  Versus a VPN, you're virtually opening a pipe to your entire network, all the time," said Sr Software Engineer & Remote.It customer.  "With Remote.It you have all these options for connections to services, but you're only actually connected to the one you're actually using."