Certyn drives native mobile and desktop apps through Appium. To test your app, Certyn needs three things: an Appium endpoint it can reach, credentials for that endpoint (if it has any), and the app to launch. This guide covers the three ways to provide them.

The easiest way is Ask Certyn: say set up mobile testing and a form walks you through it and tests the setup before it saves. Everything it saves is an APPIUM_* variable you can also edit on the Variables tab of project settings: shared values on the project, a different build or device on an environment.

Option 1: A device cloud (recommended)

BrowserStack, Sauce Labs, and LambdaTest host real devices and expose a public Appium endpoint. Nothing to install, and no tunnel or runner needed — Certyn connects straight to the provider.

Enter your credentials

In Ask Certyn (say set up mobile testing), pick your provider and enter its username and access key. They are saved as APPIUM_USERNAME and APPIUM_ACCESS_KEY (a secret), apart from the URL, and sent as basic auth on every session.

Upload your app build

Device clouds run the app from an uploaded artifact, not an app store. Use the upload page in your provider's dashboard, then pick it in the form, or set it as APPIUM_APP. The setup form links to the provider's upload instructions and capability generator. Certyn never puts your access key into a generated command or manages your builds.

BrowserStack: bs://<hash> from the app_url field
Sauce Labs: storage:filename=<your-file>
LambdaTest: lt://<id> from the app_url field

Pick a device

Pick the device (APPIUM_DEVICE_NAME, for example Samsung Galaxy S23 or iPhone 15) and the OS version (APPIUM_PLATFORM_VERSION, like 13.0 or 17) when the provider requires fixed device constraints. Sauce Labs can also allocate dynamically, so those are optional there. Provider-specific options (project names, idle timeouts, local testing) go in APPIUM_CAPABILITIES as a JSON object, for example:

{ "bstack:options": { "projectName": "My app" } }

Each Certyn session occupies one device slot on your plan while it runs.

Option 2: Your own Appium server

If you already run Appium — on a CI box, a device lab, or a Mac mini in the office — point Certyn at it with APPIUM_SERVER_URL. The URL must be reachable from where Certyn's runner executes:

Cloud runs need a public HTTPS URL (or a tunnel, see below).
Self-hosted runner runs can use any address the runner's machine can reach, including private network addresses.

For public endpoints, use Test session on the Variables tab (or in the setup form). Certyn creates a real Appium session with the configured app and capabilities, reads one screenshot or page source, and closes the session immediately. This is stronger than a /status check and may consume a small amount of provider device time.

The cloud verification action is intentionally unavailable for private endpoints reached through a self-hosted runner. Those settings are exercised from the runner during a Certyn execution instead of sending private network details through a cloud probe.

Option 3: Install Appium locally

Run Appium on the machine your device or emulator is attached to.

Install and start

npm install -g appium
appium driver install uiautomator2   # Android — use xcuitest for iOS
appium

Platform notes:

Android: connect a device with USB debugging on, or start an emulator from Android Studio. Confirm it shows in adb devices.
iOS: requires a Mac with Xcode. Simulators work out of the box. Real devices additionally need WebDriverAgent code signing with your Apple developer account.
Windows: install the driver with appium driver install --source=npm appium-windows-driver and turn on Developer Mode in Windows settings.
macOS: install the driver with appium driver install mac2; macOS prompts for Accessibility permission on the first session.

Make it reachable

A local Appium server listens on localhost:4723, which Certyn's cloud cannot reach. Two ways to bridge that:

A self-hosted runner (recommended). Run a Certyn runner on the same machine — the runner setup (in Ask Certyn, or on the Self-hosted Runners page) provisions it with one docker run command. The runner reaches Appium locally, so nothing is exposed to the internet. Use http://host.docker.internal:4723 as the Appium server URL.

A tunnel. Expose the port with ngrok (ngrok http 4723) or Cloudflare Tunnel and use the public HTTPS URL it prints. Simpler to start, but the URL changes on every ngrok restart and the endpoint is publicly reachable while the tunnel is up.

Troubleshooting

"Failed to create Appium session" — check the driver for your platform is installed (appium driver list --installed) and a device/emulator is actually available.
Device cloud rejects the session — confirm the app id is the uploaded artifact reference (bs://…, storage:filename=…, lt://…), not a bundle id, and that Device name + OS version match a device the provider offers.
Test session fails but the server is running — endpoint health alone is not enough. Check authentication, the uploaded app reference, target device constraints, and APPIUM_CAPABILITIES. The result identifies the normalized failure category without exposing the provider response or access key.
No verification button for a runner setup — expected. A localhost or private address is only reachable from the self-hosted runner, so Certyn does not probe it from the cloud.