Reuse devices across sessions to reduce start time

Reuse devices across consecutive Appium sessions on BrowserStack App Automate to skip full device resets and reduce start time.

BrowserStack App Automate allocates a fresh real device for every Appium test session by default. The standard teardown between sessions uninstalls the app and resets the device state. This adds 30 to 50 seconds to every session.

When a continuous integration build runs dozens of short test cases with the same capabilities, this setup overhead can take up most of the pipeline time. Enabling device reuse skips full device resets and keeps allocated devices active between consecutive sessions in the same build.

For background on how device setup contributes to overall test time, see start time in Optimize execution time and performance on App Automate.

How device reuse works

When BrowserStack receives a new session with device reuse enabled, it checks for a device reserved by an earlier session in the same build. That device must match the same capabilities:

• If BrowserStack finds a match, it reuses that device and skips expensive setup steps such as app download, Appium version switching, and network setup.
• If BrowserStack finds no match, it allocates a device normally and reserves it for your next matching session.

Consecutive sessions that reuse a device are called chained sessions. Between chained sessions, BrowserStack runs a minimal cleanup instead of a full teardown. It resets app state and runs health checks only.

After a session completes successfully, BrowserStack holds the device in a reserved state for about 30 seconds. Your next matching session can claim it in that window.

If no matching session arrives in that window, BrowserStack releases the device back to the general pool and allocates a fresh device for your next session as normal.

When device reuse helps most

Consider enabling this capability when your build matches most of the following:

• Your build runs many sessions, dozens or more, that share the same capabilities.
• Your sessions are short and atomic. Each session runs one focused scenario instead of a long, combined flow.
• Start time is 40 seconds or more and makes up a large share of your total session duration.

If your session start time is already under 30 to 35 seconds, the reservation wait and minimal cleanup can exceed the time you save. Device reuse may not help in that case.

Set the capability

Set the reuseDevice capability using the flow that matches your test setup.

DesiredCapabilities capabilities = new DesiredCapabilities();
HashMap<String, Object> browserstackOptions = new HashMap<String, Object>();
browserstackOptions.put("reuseDevice", true);

var capabilities = {
	'bstack:options' : {
		"reuseDevice" : true,
	},
}

AppiumOptions capabilities = new AppiumOptions();
Dictionary<string, object> browserstackOptions = new Dictionary<string, object>();
browserstackOptions.Add("reuseDevice", true);

$caps = array(
    'bstack:options' => array(
        "reuseDevice" => true,
    ),
)

desired_cap = {
	'bstack:options' : {
		"reuseDevice" : True,
	},
}

capabilities = {
    'bstack:options' => {
        "reuseDevice" => true,
    },
}

DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability("browserstack.reuseDevice", "true");

var capabilities = {
"browserstack.reuseDevice" : "true",
}

AppiumOptions capabilities = new AppiumOptions();
capabilities.AddAdditionalCapability("browserstack.reuseDevice", "true");

$caps = array(
"browserstack.reuseDevice" => "true"
)

desired_cap = {
"browserstack.reuseDevice" : "true"
}

caps = Selenium::WebDriver::Remote::Capabilities.new
caps["browserstack.reuseDevice"] = "true"

Related topics

• Optimize execution time and performance on App Automate: understand how start time, queuing, and session duration make up your total App Automate execution time.
• Capabilities and their performance impact: see which other capabilities affect start time and session duration.