Connect your workstation
VNC for the desktop. SSH for builds.
Keep coding on Windows or Linux. When it’s time to build for iOS, transfer your project to a dedicated macOS environment.
Already have an order? Sign in to the console and find your connection details in the instance overview. Never store passwords or private keys in your project repository.
Find the details in the console and enter them for the connection method you’re using.
Transfer project → Build and export → Download output
Choose your workflow
All three methods connect to the same machine, so you don’t need a separate instance for each task. Decide what you need to do, then open the right client.
Ideal for checking the environment, using Xcode’s GUI, and reviewing signing settings. The client displays the remote macOS desktop, with your mouse and keyboard controlling the cloud machine.
Start with a lower resolution. Once input, display, and connection are stable, adjust the image quality as needed.
GUI accessRun build commands for Flutter, React Native, and Unity exports, or inspect logs. Commands run remotely without continuously streaming the desktop.
A standard SSH session may end foreground tasks if it disconnects. Use a session manager for long builds, or run them with a configured build executor.
Run commandsUpload source code, assets, and config files, or download build logs and .ipa files. SFTP uses your SSH connection details—don’t enter the VNC port.
Before your first transfer, remove caches that can be regenerated. Transfer certificates and private keys separately. After downloading build output, check the file size and build version.
Project handoffSet up Windows
Install a VNC-compatible client, then open your instance details in the console. Use the connection details shown for that instance; don’t guess the address or assume a default port.
Enter the instance’s connection address in the client’s host field. The address, username, and order number are separate fields—don’t paste the entire connection guide.
If the client combines the address and port in one field, check its required format. Different clients may interpret colons differently.
Use the VNC port shown in the console. SSH and VNC are separate services and use different ports. If there’s a dedicated port field, enter the number there.
If the connection times out, check for spaces copied with the port, restrictions on that port on your current network, and whether the instance is ready to connect.
Enter the VNC password for that instance when prompted. Don’t use your console password, and don’t save credentials on a shared computer.
After opening the desktop for the first time, check the keyboard layout and system time, then verify the Xcode and command-line tools versions. If credentials seem incorrect, contact support via a ticket.
Set up Linux
Use SSH to run commands and a VNC client for GUI access. Switch between them as needed, but verify the authentication details for each separately.
Generate an SSH key on your Linux computer. Keep the private key local; add only the public key to the remote user’s authorized keys. Never upload your private key to configure login.
ssh-keygen -t ed25519 -f ~/.ssh/xcodehost
chmod 600 ~/.ssh/xcodehostAdd your public key through an authorized session or the desktop, then test key-based login. Don’t close your existing connection method until the new one works.
On your first SSH connection, you’ll be prompted to verify the host fingerprint. Confirm it through a trusted channel before accepting. If a saved fingerprint changes, check whether the instance was reinstalled; don’t ignore the warning.
ssh -i ~/.ssh/xcodehost \
-p "$SSH_PORT" \
"$MAC_USER@$MAC_HOST"Set the three environment variables in the command to the SSH port, system username, and connection address shown in the console. Enter the separate VNC details in your VNC client.
Run a build
These are example commands and excerpts of expected output, not results from a live run. The example assumes the project has been archived, signing is configured, and the upload credentials required by fastlane are ready.
$ ssh -i ~/.ssh/xcodehost -p "$SSH_PORT" "$MAC_USER@$MAC_HOST"
Last login: ...
$ xcodebuild -version
Xcode ...
$ xcodebuild -exportArchive \
-archivePath build/App.xcarchive \
-exportPath build/export \
-exportOptionsPlist ExportOptions.plist
** EXPORT SUCCEEDED **
$ fastlane pilot upload --ipa build/export/App.ipa
Successfully uploaded package to App Store ConnectRun xcodebuild -version to verify the current toolchain. For Flutter projects, run flutter doctor; for React Native, check dependencies and run pod install; for Unity, transfer the exported Xcode project first.
A successful Archive doesn’t mean the .ipa was exported, and a successful export doesn’t mean the upload is complete. Keep logs for all three stages and download the build output. If upload verification fails, troubleshoot that stage—you don’t need to reconfigure the remote desktop.
Choose a connection location
All five locations support desktop access, builds, and file transfers. The ranges shown are estimates for the listed regions—not guaranteed from every city or live measurements.
| Location | Region served | Estimated round-trip latency | Best for |
|---|---|---|---|
| Singapore | Southeast Asia | 20~50ms | Desktop work in the region; SSH builds; project transfers |
| Tokyo | East Asia | 30~60ms | Desktop debugging in the region; SSH builds; build downloads |
| Seoul | Northeast Asia | 30~50ms | Remote desktop in the region; command-line builds; file transfers |
| Hong Kong | South China and Southeast Asia | 20~40ms | Desktop work in the region; SSH builds; project uploads |
| US West | West Coast of North America | 25~35ms | Desktop checks in the region; automated builds; build transfers |
These are estimated ranges; actual latency depends on your network. Round-trip latency isn’t the same as file throughput, so it can’t predict upload or build times.
If you use the Xcode GUI often, consider a location near you. For unattended builds, also consider the route for transferring source code and build output. Check the console for current availability.
Troubleshoot lag
Choppy desktop control, failed SSH connections, and slow file transfers are different problems. Change one thing at a time and note what changes.
First lower the remote resolution and client image quality, and turn off unnecessary desktop animations. Test with short actions like typing or opening a menu; video playback isn’t a useful way to assess a development desktop.
If you only need the desktop for occasional checks, run builds over SSH instead. Keep logs and run dependency installation, Archive, and export in separate stages. If SSH works but VNC lags, check the display connection before changing your project.
Use the estimate table to choose a location near you, and check your local Wi-Fi, proxy, and bandwidth usage. Choose a location when placing your order; changing locations won’t automatically move an existing project.
Verify the desktop, SSH, and file transfers before starting a production build. Before your rental ends, download your project and build output and remove certificates and keys. Service stops when your rental expires unless renewed.