When to tunnel

If you have a testing environment that you could not access from a public library computer, you probably need a tunnel (aka Sauce Connect Proxy). Tunneling just means you're going to be able to access your private resources from a Sauce Connect machine. Whether its a real device that needs a staging API, or a Firefox browser test that needs to reach a private website you started locally, you can create a tunnel and use Sauce as if it was right there on your network.

If this sounds like you you will probably need a tunnel:

You started a webserver/api server on your workstation at localhost:some_port
You have an extensive multi-environment infrastructure running in a cloud or on premise
Your CI/CD pipeline, site, or app under test would fail if you ran it outside your network
You would like to speed up your sites load times by ignoring some HTTP requests (third party scripts and trackers for example)
You would like to redirect your site's traffic to a proxy that can collect data
You are required to use a proxy or firewall for accessing the public internet or your site under test

Ok I need a tunnel, now what?

You have a few options in HOW you utilize a tunnel. At the end of the day you'll be passing the data from a Sauce Labs Real Device or Virtual Machine to your network. Its a matter of how and when you do this. Normally your decision should be in sync with how you run your Builds.

Do you run a small number of builds every day?

If you're not running tests with every git commit you may just want to use our Jenkins or Bamboo plugin and auto-start the tunnel. This way every time you run a build you'll end up using a tunnel automatically!

Pros

its a plugin, near zero config
scales well for small groups or low numbers of tests per day

Cons

does not scale well if multiple builds are run through the same tunnel (think 100 or more tests)
does not scale well with higher numbers of tests or builds per machine
complex or security conscious networks struggle with ad hoc configuration and setup
impacts team velocity if you have to reach out to Network, Helpdesk, IT, etc for configuration and troubleshooting

Do you run a Build on every git commit?

If you kick off tests with every commit you're most likely running these from a containerized environment like Gitlab, Jenkins, or Github's Actions. In these cases you can just start by scripting a tunnel to open with a simple bash script. Then gracefully close the tunnel with a kill -15 <sauce-connect-pid>.

All-in-all you can safely start 1 tunnel and reach any localhost/temporary servers from your CICD pipeline. You will be in charge though and that could mean troubleshooting network connections between your local environment and sauce connect.

Pros

self managed

Cons

self managed

Do you run tests as part of a larger organization? Maybe hundreds or thousands of tests per day?

You will want to setup High Availability tunnels, hands down. This is just a scenario where you start a bunch of tunnels that have the same name. So you can specify that name in your tests.

Logically you can think of each "Name" as a pool so if you start these pools:

"QA-group-tunnels": 5
"Dev-group-tunnels": 4
"staging-tunnels": 8

You will have 17 tunnels running throughout your org. Some teams will have access to the tunnels, some won't! That's all controlled from the UI and the "-s" flag. Whoever starts the tunnel must us add "-s" to share it with their Team on saucelabs.com.

Pros

known path out of network + known working tunnel config once 1 tunnel is up
if a tunnel/host machine dies the other tunnels will pick up the jobs without interruption
lots of users testing during a workday? No impact on network traffic once you have enough tunnels

Cons

requires hosting 1 or more servers/machines that just run tunnels
dedicated sys admin type work needed to ensure the tunnels restart gracefully if they die