No. You don't need to install any software or extension or plugin or setting configurations of any type. Just need to login to LambdaTest, open the virtual machine through launcher, and start testing. That's the beauty of cloud. It gets you started super quick.

There are 3000+ browsers, browser versions, operating systems, devices, and resolutions to choose from. To find out about the complete list of available browsers, check out list of browsers page.

All desktop session right now are running on real browsers and operating system and are powered by real machines. Mobile browsers right now are running on both emulators/simulators as well as on real devices.

Microsoft Windows Desktop Editions licences does not support remote access to users. So we use Windows Server editions and implement Desktop experience in it. It has exactly the same experience as Windows desktop editions and they are running Internet Explorers made for desktop editions.

Whenever a new stable browser version is released we usually implement it in our platform within a week. We also test them ourselves first before providing it to customers to make sure that testing experience is optimum for all users.

Here are the operating systems and browsers running on 32 Bit Operating systems. Windows XP: Internet Explorer 8 , Firefox, Chrome, Safari, Opera Windows 7: Internet Explorer 8, Firefox, Chrome, Safari, Opera Here are the operating system and browsers running on 64 Bit operating systems. Windows 7: Internet Explorer 10, Firefox, Chrome, Safari, Opera Windows 8: Internet Explorer 10, Firefox, Chrome, Safari, Opera Windows 10: Internet Explorer 11, Firefox, Chrome, Safari, Opera All Mac Operating systems run on 64 Bit operating systems.

All our virtual machines comes with pre-installed latest versions of Adobe Flash, Adobe Shockwave, Adobe Reader, JAVA Runtime Environment, Microsoft Silverlight, and Quicktime.

You would have full access to all keyboard shortcuts. For people using same operating systems on both their local computer and virtual machine won't have any problems. However people who are using Mac machines to access Windows VM or Windows machine to access Mac VM, would have to careful about OS specific shortcuts. For example when working on Mac OS, use Control Key instead of command key for copy pasting.

Yes you can. You would have full access to download and upload functionalities. You can access Downloads folder through File - Open file, or Control+O shortcut. Be advised however, each downloaded file will be automatically erased on shutting down the sessions.

You would have full access to all browsers settings. Be advised however, if you need very specific browser settings, you would have to re-configure browser settings on starting each new session.

For Chrome and Firefox browsers, you should be able to access audio streaming and therefore should be able to hear sounds properly. For mobile emulators, Internet Explorer, and Safari, we currently dont have support to provide you access to Audio. It's because of the inherent technology involved in these browsers. We are working on a workaround though so let's see.

In the free plan you can run only one session at a time. Paid plan users can run multiple sessions depending upon their plan. Visit LambdaTest Pricing page to checkout multiple session plans and their pricing.

The number of sessions is limited by number of sessions running by a organization, not by user. Therefore it is entirely possible that you reach out of session limit even if only one or two users are using LambdaTest tool. Co-ordinate with your teammates in this case. If you are sure there is session issue from our end, you can raise a ticket at our support portal. Don't worry, we have a very fast turnaround time.

By default, if you leave the Lamdatest Live session idle for 5 minutes, the app will prompt a reminder. If no action is taken then LambdaTest would close the live session. You can change this setting from Live settings options. Checkout this link to understand more about it.

Switching tab won't stop or pause the Live session. If left idle for 5 minutes or more, LambdaTest will prompt a reminder and if unanswered will close the session.

The moment you close the session, LambdaTest automatically sanitize the whole virtual machine. What that means is that we delete all historical data, downloads, installed extensions, saved passwords, etc. We reset the browsers to factory settings. This automatically logs you out of all pages and auto deletes all data that you may have saved. You would still have access to screenshots and issues you may have generated during the session.

Yes! Every time you close a session we would reset all settings. We are working on a way to help you change and save a set of customized default browser settings. If your need is critical and changing browser settings in each new session takes a lot of your time, send us a message from here. We will try to find a solution for you.

There may be a number of reasons why this happened which include LambdaTest test flagged the IP for excessive spam registrations. LambdaTest flagged the IP for violating terms of use or privacy policy To prevent our system from spam or security threats If you think that your IP has been flagged erroneously, raise a ticket at our support centre.

LambdaTest test system allows only a limited number of concurrent running sessions per organization. This limit is defined by the plan that you have subscribed. If you need more concurrent sessions, you can change your plan, or contact one of our sales executive.

It's simple. In real time browser, on left side you will find multiple action buttons in the controller. One of them will be a screenshot button with camera icon. Just click that and in no time your screenshot will be recorded. Once recorded, an image editor will pop up where you can edit the screenshot, mark it as a bug and comment about the details. Lastly, you can find them anytime in test logs section of the menu.

By going to the Issue tracker, you can add your teammates as watchers for the particular issue and you can also assign them the issue by marking them as 'assignee'. Incase the team-mate is not added yet, you will also find an option in the tracker to invite them.

LambdaTest Live has all major developer debugging tools like Firebug, Web Developer, YSlow etc.

Yes! You have full access to browser extensions and therefore can install any additional tool you like. However that tool be deleted once you close the Live session and you would have to reinstall it again in next session to use. If you are facing any problem around installing a tool on browser, raise an issue in LambdaTest Support portal and we would be glad to help you out.

WebdriverIO is a browser and automation test framework based in Node.js. Adding helper functions in WebDriverIO is really simple in WebDriverIO. Also, it can run both on WebDriver protocol and Chrome Devtools protocol, making it efficient for both Selenium Webdriver based cross browser testing or Chromium based automation. To top it off, since WebDriverIO is open source, you get a bunch of plugins for your automation needs.

The LambdaTest Selenium grid doesn’t identify if you test ‘passed’ or ‘failed’. It only identifies whether a test has executed to it’s last command or whether it has stopped/timed-out before it. The user would have to pass on these parameters to LambdaTest platform to make it possible for tracking these values at LambdaTest platform. Make use of LambdaTest API or LambdaTest Annotations, for pushing additional metadata to LambdaTest or to track the pass/fail status of a test.

Yes! One of the key features of LambdaTest Selenium grid is the ability to run your test cases in parallel. Which means you can execute numerous automation test cases altogether and enable you to cut down on test times. With LambdaTest Selenium grid you can run a single test scenario across different browsers or different test scenarios with the same browser (or any other combinations). Wondering how many parallel test cases can you run? That depends entirely on the number of concurrent sessions under your opted plan.

Maximum number of test cases that can be queued = n + 150 Here, n = number of concurrent sessions. For instance, if you are opting for pricing where you can avail up to 10 concurrent sessions. Then the maximum number of test cases that can be queued will be equal to 10 + 150 i.e. 160 queued test cases. LambdaTest would automatically schedule and execute test cases for you. We have added a capacity constraint on the number of tests that can be queued to prevent over-exploitation of the platform. Refer LambdaTest Queuing Policy to know more.

LambdaTest Concurrency Calculator is here to help you calculate the number of parallel sessions you need for your test coverage. Feed the information to our Concurrency Calculator, and it would suggest to you the appropriate number of parallel sessions.

By using Live-Interaction, you can take over the automation test execution manually. You can abort the automation test session and debug in real-time.

You should be on five parallel sessions or above.

To interact with a browser manually in an automation test, you can visit the LambdaTest Automation dashboard and then click on Click to view live test to take control of the browser.

The maximum time limit for Live interaction is 15 minutes.

The Live interaction is accessible across all browsers except Safari for Windows 11, 10, 8.1, and 8, and macOS Big Sur.
Note: The Live interaction support on Safari browsers will be available soon.

The status of the test changes to `idle_timeout`` if you abort it using Live interaction.

Once you access Live interaction, and abort a test, the test will time out within one minute if no keyboard or mouse events are recorded on your respective machine.

In this case, there is no such limit.

To know more about browsers, OS, and devices supported by LambdaTest Automated Screenshot testinf, checkout list of browsers page.

Yes. You can share these screenshots with your team. To know more about how you can do it, check out this tutorial guide on Automated Screenshot testing.

LambdaTest comes with enterprise level local tunneling features. You can connect your local or production servers with LambdaTest Servers via secure SSH protocols and test your secure pages easily.

LambdaTest won't stop or pause the screenshot generation process. LambdaTest Automated Screenshot feature will generate screenshots and then will wait for your further actions.

Currently, we support the following file formats for Realtime Native Mobile App testing:

• For iOS, .app and .zip format.
• For Android-x86, .apk format.

Currently, we don’t support the testing of apps from the Google Play Store/App Store on emulators/simulators.

For now, we don’t support ipa files on iOS simulators.

As a part of the freemium plan, you get one-time, non-renewable access to a limited set of devices (emulators and simulators). It limits to a maximum of 5 app uploads and 100 free minutes.

Accessing hardware peripherals like camera and mic is currently not supported on emulators/simulators.

Gesture is currently not supported on emulators/simulators.

Yes! you can use Developer Tools for viewing the device logs, network logs, and app logs. Inspect element is currently not available on emulators/simulators.

As ipa files are not supported on iOS simulators, you would encounter ‘App Not Found error’.

You need to install the app being tested and the dependent app (e.g. Google Maps) in the same session.

As per our data retention policy, all uploaded apps will be deleted after sixty days.

Emulators on which App testing is performed work on the x86 architecture. Hence, your .apk file should be built for x86 architecture to ensure seamless testing on LambdaTest platform.

Any premium plan will allow you to test apps on emulators/simulators. The number of parallel sessions will depend on your parallel session plan. Refer to our plans and pricing page for further information.

Through On-demand pass you can get 120 minutes of manual testing time on LambdaTest platform at $10 for 30 days. Currently, On-demand pass is not covered for Realtime Native App testing.

You need not opt for a seperate App Testing Plan, as parallelism (or concurrency) for app testing is synced with Realtime Browser testing. To run native mobile app tests parallely (or concurrently) with Realtime Browser testing, you need to ‘at least’ be on a two (or more) parallel session plan.

Currently, we support the following file formats for App testing on real devices:

• For iOS, .ipa format.
• For Android, .apk and .aab format.

No! Following each test session, the devices are thoroughly cleaned. During this phase, we uninstall the app and clear the user data and configurations generated on the device during the test session.

Currently, we support Appium framework. However, support for other frameworks will be rolled out soon

Currently, we don’t support the QR code scanning of apps on real devices.

Accessing hardware sensors for biometric authentication is currently not supported on real devices.

The app file .apk can be generated using the command → ./gradlew assemble which saves the generated file in this directory → app/build/outputs/apk/debug/. The Test Suite file .apk can be generated using the command → ./gradlew assembleAndroidTest which saves the generated file in this directory → app/build/outputs/apk/androidTest/debug/

Currently, the Charles proxy for network traffic monitoring is not supported on LambdaTest.

For debugging test failures, LambdaTest App testing supports Appium logs, Visual logs, Device logs, Network logs, and Command logs.

You can test locally hosted and apps behind firewall by performing local testing through LambdaTest tunnel.

Yes. Network throttling is supported on LambdaTest real device cloud platform.

Yes! You can test location-based cases for your app with GPS Geolocation testing.

No! Only major versions of the Android and iOS are supported.

We provide the latest browser versions on real devices. However, the choice for browser versions like Chrome 94 or Firefox sub-versions are not available.

We support the following developer tools for Browser testing:

• Android - Chrome
• iOS - Safari and Chrome

Currently, our real devices do not support SIM cards/eSIM. Therefore, phone calls or SMS cannot be received on the device. You can test OTP-based cases, but the SIM card must be present and accessible to the user in their local device.

Currently, App profiling data on real devices are not supported

Yes, you can test both in-app browsers and Hybrid apps on our real device cloud.

As of now, the dedicated devices are not supported on the LambdaTest platform.

Currently, we don't support Mobile App automation on Emulators and Simulators.

The maximum session duration of Appium tests is 4 hours.

As of now, we don't support uploading files from the app installed on real devices.

Currently, we don't support uploading and downloading files while perform Manual App testing on real devices.

To open the pre-installed apps, run the below command.
driver.activateApp("package_name");

To see the apps, you will need to login on the Google Playstore.

As of now, Apple Pay functionality is not supported on real devices.

Currently, we don't support Performance testing frameworks.

If the captive portal requires the device to be connected to a specific WiFi network, you cannot test it on real devices. However, if the same webpage can be accessed using the default WiFi network or tunnel, you can test it on real devices.

ADB (Android debug bridge) is a command-line tool for communicating with Android devices. The ADB command enables a variety of device actions, like installing apps, granting permissions, copying files, performance profiling, and so on.
We do not expose the ADB shell to protect the security of devices and users. However, the same functionality can be achieved by using an equivalent Appium capability or LambdaTest customer capabilities.

Yes, you can interact with the alert or actionSheet popups that are configured in your iOS application.

To generate "app_url" using the cURL command, please refer to our Appium testing documentation.

For resolving the localhost URL for the real device, you can use localhost.lambdatest.com.

60 days

For iOS 13 and above, Apple prevents the streaming of the keyboard and the streaming of the password field whenever a password is being entered. This is part of its enhanced security features. Therefore, even if the password is entered successfully, you will not be able to see the keyboard, keystrokes, or characters entering the password.

To generate "app_url" using the cURL command, please refer to our Appium testing documentation.

For resolving the localhost URL for the real device, you can use localhost.lambdatest.com.

60 days

For iOS 13 and above, Apple prevents the streaming of the keyboard and the streaming of the password field whenever a password is being entered. This is part of its enhanced security features. Therefore, even if the password is entered successfully, you will not be able to see the keyboard, keystrokes, or characters entering the password.

Network logs on Real Devices and specifically on Android devices have some known limitations. Enhancements are currently under development and will be communicated to you based on your use cases.

To generate "app_url" using the cURL command, please refer to our Appium testing documentation.

For resolving the localhost URL for the real device, you can use localhost.lambdatest.com.

60 days

For iOS 13 and above, Apple prevents the streaming of the keyboard and the streaming of the password field whenever a password is being entered. This is part of its enhanced security features. Therefore, even if the password is entered successfully, you will not be able to see the keyboard, keystrokes, or characters entering the password.

Network logs on Real Devices and specifically on Android devices have some known limitations. Enhancements are currently under development and will be communicated to you based on your use cases.

We currently support Appium logs, Visual logs, Device logs, Network logs, and Command logs on real devices.

The app file .apk can be generated with the command ./gradlew assemble, which saves the generated file in the directory app/build/outputs/apk/debug/
. The Test Suite file .apk can be generated using the command ./gradlew assembleAndroidTest, which saves the file in the directory app/build/outputs/apk/androidTest/debug.

You can run test for 6 hrs uninterrupted on a device.

For Android, long press can be accessed by intimating long press on your mouse/trackpad. For iOS, the action can be triggered via CMD+click for macOS and via CTRL+ click for Windows.

The new device addition requests can be catered to in 6-8 weeks’ time.

This use case is not feasible at the moment as we do not support testing of Smart devices(Amazon Alexa) on the LambdaTest platform.

Yes, you can test video calling apps on LambdaTest's Real Devices but as the Camera is taped due to security reasons so it will show black image and audio will be blank as well.

In order to handle the location pop-up, you can use below capability in the script and the location will be auto handle in the test.
caps.setCapability("autoAcceptAlerts", true); 

Please note that autoAcceptAlerts: true won't work on iOS devices with iOS 14. This is a known issue and already raised on Appium.

Note: For iOS 13 and above, pop-ups can have more than two buttons. When there are more than two buttons on popups, autoDismissAlerts and autoAcceptAlerts behavior is flipped. For such popups, use autoAcceptAlerts to automatically dismiss all popups and autoDismissAlerts to automatically accept all popups.

Yes. Open you website in any device and click on the video recording button, a timer will start and you will be able to record your interaction of the website within the device. The timer will continue to run unless you stop the recording by clicking over the same video recording button.

Yes. All you need to do for testing your locally hosted web-apps or websites, is to provide the localhost string as the URL in the header of your LT browser and you’ll be able to access your localhost server.

With LT Browser, not only can you evaluate how your responsive web design might look over 50+ pre-installed device viewports but you can also debug your web-application to figure out the root cause behind a browser or UI bug.

LambdaTest is a firm believer in secure experience and multifaceted security protocols, to ensure that every aspect including architecture, engineering, testing, and deployment, follows and complies with industry leading standards of security. As first line of defense, LambdaTest application is protected by AWS’s firewalls which are tasked with countering regular DDoS attacks and malicious network intrusions. The next line of defense is LambdaTest’s own application firewall protocols which are tasked with protecting the application against spam, ill-intent users, and malicious IP. We have also implemented secure user access policies for accessing LambdaTest platform and only users with valid user credentials can access the application. We have also implemented role based access to the application, each role having different access levels.

Whenever a user initiates a test at LambdaTest platform, they are allotted a thoroughly sanitized virtual machine. And as soon as a session ends, all data including cookies, registry, caches, and running processes are deleted and all browser settings are reset to default values. Each virtual machine has to pass a series of automated tests before it is used again. Any machine that fails a test gets redacted from the pool for auditing and manual cleaning. At the time of test only the user has access to machine and not even LambdaTest has access to the user’s running test session. All machines have strict security protocols that prohibit any user from installing any external software in the machines.

In our application we have implemented HTTPS by default, and use VNC protocols for secure data transfer. This data is also encrypted to ensure that data is not compromised in-transit.

All our hosting centers are chosen based on their record of established security policies and excellent history. Our selection process is rigorous and we partner with only the best providers across globe that have been certified by major compliance regulators.

All data saved in our application like login credentials, secure access keys, usage logs, test history, and billing details, are stored in an encrypted format.

We have implemented strict 24×7 security protections at our on-premise development centers. Only authorized individuals have access to building and LambdaTest office premises. Our application data is hosted on industry leading hosts like Amazon Web Services, who have been thoroughly tested by multiple third party auditors for security. You can also read more about Amazon Web Service’s Security AWS Cloud Security

LambdaTest has a formal Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) defined and implemented to enable people, process, and technology support during any crisis or business interruptions. The BC and DR Plan is tested and reviewed on a yearly basis. And, Disaster Recovery (DR) program ensures that our Services remain available and are easily recoverable in the case of a disaster. This is accomplished through building a robust technical environment and creating Disaster Recovery plans and testing activities. In the event of a disaster, the following objectives apply:

1. 4-hour Recovery Time Objective (RTO): LambdaTest will aim to restore normal operations for your LambdaTest platform account within four hours from the time a disaster is declared, unless a disaster, or multiple disasters, impacts all of the Availability Zones used on an account.
2. Under 1-hour Recovery Point Objective (RPO): LambdaTest will target one hour or less of data loss for your account. This is calculated from the point of the disruption, not from LambdaTest’s disaster declaration.



Also, LambdaTest employs service clustering and network redundancies to eliminate single points of failure. Our strict backup regime and/or our Disaster Recovery service offering allows us to deliver a high service availability, as customer or test data is replicated across availability zones.

For more details, please refer to LambdaTest Trust page.

Yes. All our employees sign confidentiality agreements which extends to user agreements between LambdaTest and Clients. Also, we have strict user role based access to all our customer data therefore, only most important employees have access to only relevant data.

Yes, we have Service Organisation Control (SOC2), CCPA and GDPR report compliance certification.

Our application is micros-services based product. Database is restricted from public access. It is only accessible to the application though encrypted authentication based APIs and that also over a secure private network.

We at LambdaTest follow Agile development methodologies with dedicated teams for automated deployment and testing. We use Jenkins as our preferred Continuous integration platform and use Sonar Cube for automated code quality control. We ensure maximum possible code coverage in our automated tests and each release is passed only before it pass all test scenarios.

We periodically tests our applications for vulnerability both through automated and manual means. We perform regular audits of databases to check for irregularities, and our ELK stack implementation gives real-time insights on any possible attacks.

Access to production system is strictly controlled though role based authentication access. No LambdaTest employee has complete access to all data, each having their relevant role based access to data. Each employee has his/her own email based authentication passwords for accessing applications and after termination we revoke their complete access to the application. In addition we maintain automated logs of each database ingress and regularly monitor the logs to find discrepancies.

All user access is password protected. In addition user sign-ups are verified through a two-step verification workflow.

At LambdaTest, we maintain a variety of logs such as syslog (system logs), auth (authentication) logs, firewall logs, web server logs, application server logs, database server logs, netflows etc. We have an inhouse implementation of ELK stack for logging and business intelligence. Our implementation gathers and consolidates data from all micro-applications into a secure private network. The data is used for product analysis by product team through our custom log processing and BI system. The BI system in turn is secured thorugh a IP based access policy. In addition only authorized LambdaTest employees has access to relevant pieces of data based on their role. All log data is saved in encrypted format private storage volumes that is encrypted usign DM-Crypt disk encryption system

We follow SemVer versioning standards and publish hot-fixes and patches as it is required.

Yes. We have separate Production, Dev, and Test Environments. Each Environment is hosted in separate instances and is secured behind a private network.

All environments are hosted on independent AWS instances. Only Live environment has critical user data. Rest of the environments have dummy or simulated data that covers all use cases.

We perform periodic system vulnerability scans, both automated and manual, using a OpenVAS based solution. We check for all major vulnerabilities and security risks as enlisted in open source databases like national vulnerability database.

Our application is hosted on Amazon Web Services and we follow all DDoS mitigation guidelines detailed by AWS in this documentation paper. We use services such as Amazon Route 53, Amazon CloudFront, Elastic Load Balancing, and AWS WAF to control and absorb traffic, and deflect unwanted requests. We also have a Cisco ASA firewall in place as added security measure. In additon to all this we have put into place custom firewall and security measures based on Fail2Ban intrusion protection framework to prevent brute-force attacks.

We have implemented advanced analytics using Kibana, Kubernetics, and AWS data tools. We monitor all our networks constantly for suspicious activity. We also use Elastic.co’s Beats product for shipping data. Beats comes with in-built monitoring and data visualization tools that help in real-time monitoring of application.

Yes. All user credentials are stored in a manner compliant with all NIST guidelines as defined in NIST special publication.

All user data is stored as encrypted data in secure AWS storage hosted databases. We use AWS S3 for data storage and have enabled advanced 2048bit Public Key encryption standards for Data at Rest. For Data in transit we use VNC and WSS security and encryption protocols.

All data such as user credentials are secured in encrypted format and no LambdaTest employee can access it, including administrators. User data such as company details, user contact details, test logs, etc. can be access by only relevant developers. We have strict user role based data access and only relevant developers have access to parts of user data. This security access is audited every month based on development and testing sprint plans.

We use AWS services like AWS S3 to store and take backups of our data. All data stored on AWS instances are stored using advanced AES256 encryption standards. Any data that is not critically required gets deleted through standard DELETE requests on S3 buckets. However we have implemented versioning and rollback steps to prevent accidental deletion of data. Therefore, even delete requests do not immediately delete all data. For that we have implemented provisions to scrub all data including the historical backup data on client requests.

Our application is hosted entirely on third party hosting providers like AWS, Hetzner, etc. All our hosting partners have very high security protocols. For example checkout AWS security protocols, or Hetzner Security protocols.

We, here, at LambdaTest follow a 6 step incident reponse process. The various stages of the response proces are prepration, identification, containment, eradication, recovery, and learning. We use industry leading practices for each step and test our response workflow once a month.

In case of an identified breach, all related users are notified of the breach immediately so that they can take necessary measures to prevent further loss. We share this information with our signup users through our email channels, and also notify users through social media platforms like LinkedIn, Facebook, and Twitter.

None. Only web requests initiated on LambdaTest platform are transported to your localsystem via SSH tunnel created by our tunnel binary. The data at rest and data at transit are both encrypted. Only web browsing data generated by a webbrowser selected on LambdaTest platform can send data to your system. As such your system is not exposed to public. In addition, every tunnel created using Lambda Tunnel binary is isolated to users of the same account. All Information of the remote tunnel is secured by accesstoken and we employ latest technology in encrypted tokens. This information is only provided to the browser fired the user. With that said, LambdaTest recommends using test data instead of production data as best practice.

When you sign up with LambdaTest, you receive 60 mins/month Realtime Browser Testing (6 Sessions of 10 minutes each), 100 Automation Minutes for 15 days, 10 Screenshot Tests per month, 10 Responsive Tests per month, 24x7 Support, and 3rd Party App Integrations. The Free Trial is the best way to get a feel for LambdaTest and how it works. LambdaTest is ideal for teams, and therefore you can invite any number of users to be part of your LambdaTest Team for testing.

When you sign up, you instantly get access to our Freemium plan. This plan has no trial time limit, it's there for you for Life. In the freemium plan you get 60 minutes of LambdaTest Live testing usage which gets renewed per month. You can anytime upgrade your plan for more robust features and unlimited access to LambdaTest Live Testing machines.

You can add more user accounts to your existing plan, or upgrade to another plan from the Pricing page. Upgrades can be done any time, and are charged on a prorated basis. Thus, if your subscription is changed during a billing cycle, your billed amount for the month will be prorated. To know more, visit LambdaTest Manage Subscription documentation.

We accept all types of credit and debit cards for payment. We have provision of payment using PayPal payment method as well.

Yes, you will receive the invoice for the subscription opted. Invoice will be sent by default to the email ID that was used during sign up. You can also download the invoice from from your user account.

Live parallel sessions indicate the number of tests you can conduct at the same time. For example, if you have opted for 2 parallel sessions, two members of your team can execute live testing simultaneously. Or a single member can run 2 parallel sessions.

Pricing is purely based on parallel sessions. User limit is an add-on which comes along with the editions.

LambdaTest price is based on plan level and the no. of parallel sessions. As per your need you can upgrade and downgrade at any time. However, changes will not take effect until your next billing cycle.

An On Demand Pass is a one time payment option for to those who wish to use LambdaTest for a shorter duration. With On Demand Pass, you get 120 Minutes of testing time with full access to LambdaTest features for 30 days at a price of just $10. This is a non recurring payment ,i.e. if you wish to continue this plan you would have to purchase On Demand Pass again.