Developers commonly set up servers to create a personal development environment that supports their work. These servers are sometimes located in an office’s server room, or under the desks of developers (providing easy access in case of maintenance issues, and also for performance reasons). After the COVID-19 pandemic started, one of our customer’s offices became physically inaccessible, so some of their developers took their servers home.

However, this raised an issue of sharing access to that development server with coworkers, since these servers were now sitting on home networks rather than the office network. Sharing access to development servers allows developers to collaborate - such as sharing in-progress work for testing or review, without requiring others to spin up their own servers.

Two common workarounds - port forwarding and setting up a VPN - make developers uncomfortable. Each workaround makes elements of a user’s home network visible to the internet, creating an exposure to attackers and placing a heavier burden on the developer to secure their network.

Twingate is a solution for a situation like this. With Twingate, not only can resources on private home networks be made accessible to specific coworkers, but access can also be narrowly restricted to individual resources on that network (in this case, just the development server).

Importantly, Twingate is architected in a way that does not require users to expose any element of their home network to the internet. No router ports need to be opened, and no VPN server needs to be deployed. In fact, nothing about the user’s existing home network needs to be reconfigured. This keeps the home network safe from third parties, and only the development server is made accessible to coworkers who have expressly been granted access.

This use case can be implemented by the user deploying a Connector on their development server, and adding the development server as a resource in Twingate.