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!
- its a plugin, near zero config
- scales well for small groups or low numbers of tests per day
- 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.
- self managed
- 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.
- 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
- 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