The CLI Doesn't Have to Stop at Your Firewall.
Locked-down corporate networks used to mean cloud-connected CLI tools just didn't work from inside them. The TestSprite CLI can be configured to route its traffic through a corporate HTTP/HTTPS proxy, so it runs the same way behind your firewall as it does anywhere else.
Built Into the Same CLI You Already Run
Configured Once, Works Everywhere
Set up the proxy alongside the rest of your CLI configuration, and every command — test generation, reruns, artifact pulls — routes through it automatically.
No Special Network Exceptions
The CLI reaches TestSprite's cloud sandbox through the same corporate proxy your other developer tools already use, so there's nothing new for a network or security team to approve.
Works in CI, Not Just on Your Laptop
Setup can run non-interactively with testsprite setup --from-env --yes --agent <name>, so proxy configuration carries cleanly into CI pipelines running behind the same network policy.
Credentials Stay Managed Separately
Proxy configuration and stored project credentials via project credential are independent, so switching networks doesn't mean re-entering API keys.
$ testsprite doctor Checking CLI environment... Node.js version — OK Network connectivity — OK (via corporate proxy) TESTSPRITE_API_KEY — found $ testsprite setup --from-env --yes --agent claude Reading TESTSPRITE_API_KEY from environment... Corporate proxy detected — routing CLI traffic through it Setup complete.
Don't Let Network Policy Decide What You Can Automate
Developers at companies with locked-down network policies often can't use cloud-connected CLI tools at all — every outbound request gets blocked before it leaves the building. Proxy support means the TestSprite CLI works within that policy instead of asking for an exception to it.
Built for Teams Behind a Corporate Firewall
Works With Standard Corporate Proxies
Configured through the CLI's own setup flow, so IT doesn't need to open a direct path to the internet for TestSprite specifically.
Fits Into Existing CI Pipelines
Non-interactive setup with testsprite setup --from-env --yes --agent <name> carries proxy configuration into GitHub Actions, GitLab CI, or any runner sitting behind the same policy.
No Separate Enterprise Build
Proxy support lives in the same CLI you already installed with npm install -g @testsprite/testsprite-cli — there's nothing extra to request or license.
Pairs With Credential Management
Use project credential to manage stored credentials per project, independent of how the CLI reaches TestSprite's cloud sandbox.
Trusted By Businesses Worldwide
"TestSprite offers rich test case generation, clear structure, and easy-to-read code. It also supports simple online debugging with the ability to quickly expand by generating new test cases."
"TestSprite's automation helps us reduce tons of manual work. The developers can easily catch and resolve bugs earlier in the development process."
FAQ
Does the TestSprite CLI work behind a corporate HTTP/HTTPS proxy?
Yes — proxy support was added in CLI release v0.3.0. The CLI can be configured to route its traffic through a corporate proxy instead of reaching TestSprite's cloud sandbox directly.
Why does this matter if I'm not on a locked-down network?
It doesn't change anything for you — proxy configuration is optional. It matters for developers at companies where all outbound traffic has to pass through an approved proxy before it reaches the internet at all.
Does proxy support change how tests actually run?
No. Frontend tests still run against a live URL through a browser, and backend tests still run against a base URL, both executed in TestSprite's cloud sandbox with Auto-Heal for brittle selectors. The proxy only changes how the CLI reaches that sandbox.
How do I set up the CLI on a network like this?
The same way you'd set it up anywhere else — interactively with testsprite setup, or non-interactively with testsprite setup --from-env --yes --agent <name>, which reads your API key from the TESTSPRITE_API_KEY environment variable.
Does this affect how my project credentials are stored?
No — proxy configuration and credential storage via project credential are handled separately, so how the CLI reaches the network doesn't change how it manages your project's credentials.
Your Network Policy Shouldn't Block Your Test Automation.
Install the CLI, point it at your corporate proxy, and run the same test automation your team already relies on — without asking security for an exception.