Your plan is for a dedicated physical machine, not a VM. Find the host, port, and login credentials in the console. Use SSH to run tasks, screen sharing to work in the GUI, and file transfer to retrieve your output.
Before connecting for the first time, confirm that your order has been provisioned. Never include passwords, private keys, or complete connection credentials in an email.
Start here to compile, run scripts, and inspect the system. Use the port shown in the console—don't assume it's the default port.
Open the relevant instance in the console and check the host address, SSH port, and username. Preserve the exact capitalization and symbols in your password. Replace the sample variables below with your own details in a local terminal; enter your password when prompted.
On your first connection, you'll be prompted to verify the host key. Check its fingerprint against confirmed console information or a support ticket before accepting it. If the host key changes, first confirm whether the machine was reinstalled or replaced. Don't ignore the warning or disable host checking globally.
Generate a dedicated key with a passphrase on your local machine, then add the public key to the remote user's authorized keys file. Keep the private key on your own computer. Have each team member use a separate key so you can revoke access individually—never share one private key.
Keep your current working session open, then test key-based login in another terminal. Once it works and you have a console recovery path ready, update the SSH service's password authentication setting. Check the configuration syntax, then apply it using the service method for your system. Disabling password authentication does not disable all interactive authentication.
Run in a local terminal; replace the three connection fields first
HOST='host-address-from-console'
SSH_PORT='ssh-port-from-console'
REMOTE_USER='username-from-console'
ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST"
ssh-keygen -t ed25519 -f "$HOME/.ssh/xcodenet_ed25519"
cat "$HOME/.ssh/xcodenet_ed25519.pub" | ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST" 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ssh -i "$HOME/.ssh/xcodenet_ed25519" -p "$SSH_PORT" "$REMOTE_USER@$HOST"Run the public-key append command once. If a key already exists, don't overwrite it—choose a different filename. Before changing authentication, ports, or firewall settings, make sure you have a recovery method so you don't lock yourself out.
These are example steps, not live output from your instance. Xcode builds require your project and the correct tool path. Fastlane distribution also requires your own signing configuration and release authorization.
$ ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST"
Welcome to macOS
$ uname -m
arm64
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ cd ~/workspace/App
$ xcodebuild -scheme App archive
BUILD SUCCEEDED
$ fastlane beta
Successfully uploaded to TestFlightuname -m Use this to check the current system architecture. Native toolchains should match the arm64 environment. If a dependency fails, check the binary architecture first; a successful connection doesn't mean the environment is fully configured.
xcode-select -p Shows the current developer tools directory. After switching Xcode versions, check it again, then verify your project's SDK, scheme, and signing requirements.
Successful Fastlane distribution requires valid certificates, provisioning profiles, and release authorization. Store sensitive files in a restricted directory, keep them out of your repository, and never print them to public build logs.
Finally, check release accessConnect to the desktop when you need to use Xcode, the Simulator, or system settings. GUI responsiveness depends more on round-trip latency and connection stability. Get a reliable connection first, then increase image quality gradually.
On your Mac, open Connect to Server from Finder's Go menu and enter the connection address shown in the console. Use the instance's graphical login credentials—not your console account password.
If you're connecting through the SSH tunnel below, use vnc://127.0.0.1:5901. Keep the tunnel terminal running; closing it stops port forwarding. Don't expose the desktop service to the public internet to bypass the tunnel.
Enter the host, port, and instance credentials in your client. Prefer a client that supports SSH tunneling or explicitly provides encryption. The VNC protocol itself doesn't guarantee encryption in every implementation, so a successful connection alone doesn't mean it's secure.
Start with one display at a lower resolution and turn off unnecessary desktop animations. Prioritize readable text for work. For video previews, use proxy media and download the final output to check locally.
Start smooth, then improve image qualityEncrypted tunnel example: the remote desktop service must be enabled; check the instance settings for its listening port
VNC_PORT='5900'
ssh -N -L "127.0.0.1:5901:127.0.0.1:$VNC_PORT" \
-i "$HOME/.ssh/xcodenet_ed25519" \
-p "$SSH_PORT" "$REMOTE_USER@$HOST"This example binds the local port to the loopback address only; it isn't exposed to your local network. If local port 5901 is already in use, choose an available port and update the client address to match. If the screen is blank, check the remote user session and desktop service instead of repeatedly reinstalling the client.
File transfers use the same SSH host, port, and key. Test the path and permissions with a small file before uploading the full project. Replace the directories in the commands with your own paths.
Ideal for archives, build logs, and completed exports.scp uses an uppercase -P, unlike ssh , which uses lowercase -p . Create the destination directory on the remote machine in advance and make sure it's writable.
Ideal for syncing code and assets incrementally. A trailing slash on the source directory means sync its contents. On the first run, add --dry-run to preview what will sync. Don't add a deletion option casually, or you could remove files that exist only on the remote machine.
Confirm the remote directory first; these examples don't delete files
scp -P "$SSH_PORT" -i "$HOME/.ssh/xcodenet_ed25519" \
./App.zip "$REMOTE_USER@$HOST:~/uploads/"
scp -P "$SSH_PORT" -i "$HOME/.ssh/xcodenet_ed25519" \
"$REMOTE_USER@$HOST:~/exports/App.zip" ./downloads/
rsync -av --dry-run \
-e "ssh -p $SSH_PORT -i $HOME/.ssh/xcodenet_ed25519" \
./project/ "$REMOTE_USER@$HOST:~/workspace/project/"
rsync -av \
-e "ssh -p $SSH_PORT -i $HOME/.ssh/xcodenet_ed25519" \
./project/ "$REMOTE_USER@$HOST:~/workspace/project/"Need more space for large projects, model files, or media? Add an external +1TB SSD for $2.2/day or +2TB SSD for $4.4/day. An add-on drive doesn't change the primary storage specifications of available models. After connecting, use df -h to check the actual mount point and available space, then set your download, cache, and export directories.
Already-compressed video, audio, and archive files usually won't benefit from further compression for transfer. After transferring important outputs, verify their size or checksum and keep a local copy. A successful sync isn't a backup.
Two models are available in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East Coast, and the US West Coast. These locations are suggestions, not guaranteed latency targets. Check the console for current availability.
A location to compare if you're in Southeast Asia. For screen sharing, check round-trip latency from your local network. For team CI, also test the routes to your code repository and artifact storage.
Two models availableA location to consider in East Asia. For GUI debugging, test text scrolling and window dragging. If you'll mainly use SSH, compare dependency download and build artifact transfer speeds too.
Two models availableA location to compare in Northeast Asia. Remote Simulator use is sensitive to connection jitter. Test at the same resolution and image quality to avoid mistaking client settings for differences between locations.
Two models availableA location to compare if you're in South China or Southeast Asia. First, use a wired or otherwise stable local connection to rule out Wi-Fi interference. Then check screen sharing and sustained transfer stability.
Two models availableA location to consider in eastern North America or Western Europe. For CI, compare routes to your team's code source, dependency services, and artifact storage—not just the distance from you to the machine.
Two models availableA location to compare if you're on the US West Coast. For interactive development, prioritize round-trip latency. For batch builds, focus on total task runtime and artifact delivery; the best location may differ for each.
Two models availableFor a provisioned machine, start by running ping -c 10 "$HOST"to check round-trip time and packet loss. Some networks don't respond to ICMP, so that alone doesn't mean SSH is unavailable. Next, use the same client settings to operate the desktop and transfer the same test file. Record the time, local network, resolution, and results so support can reproduce the issue.
We don't present location-based estimates as measured latency. Your carrier, cross-region routing, Wi-Fi environment, and client image quality all affect performance. Test your workflow for a day before extending your rental—it's more reliable than judging by map distance alone.
A dedicated node doesn't mean access controls are already configured. Tighten permissions in this order: keys, sources, services, cleanup. Always keep a verified recovery path.
Changing the SSH listening port can reduce routine scan noise, but it doesn't replace key-based authentication. First check whether port forwarding and network rules allow the change. Update your client settings and team documentation, then verify the connection in a new session.
Allow only necessary sources in the access rules supported by your instance. Your office egress or home public IP may change, and mobile networks may use different egress IPs. Check your current egress IP before applying a rule and understand how to recover if it changes.
The macOS application firewall and rules that filter by port or source serve different purposes; check both. Allow only the connection services you need and disable unused ones. After each change, test SSH and desktop access from a second terminal—don't apply several changes at once.
Sync your project, build outputs, and experiment notes first. Then revoke temporary release authorization, remove team public keys, and clear sensitive files from certificates and caches. Confirm your backup is readable before wrapping up; don't rely on data being retained after your rental ends instead of making a backup.
A support ticket only needs the instance ID, the issue, and what you've tried. Don't send private keys, login passwords, signing certificate passwords, or payment card numbers. Redact credentials in screenshots too. If support staff need to access the instance, specify the scope of authorization in your ticket.
It's usually faster to identify whether the error is a timeout, connection refused, or authentication failure than to keep clicking Connect. Check the items in order, save the original error, then submit a support ticket through the help page or console.
Confirm payment and provisioning status, then open the correct instance details. If connection credentials aren't shown yet, check the order status first. Don't guess the address or copy details for another instance from old notes.
Compare the host, port, and username with the console, one by one. For a timeout, check the network and access rules first. “Connection refused” usually means you should check the service listener, port, and forwarding settings.
If authentication fails, confirm you're using the right private key, remote user, and public key authorization file. Use ssh -v to inspect the authentication process. Before sharing logs, remove sensitive details such as the host, username, and local paths.
Check your proxy, company network policies, and any recently changed firewall rules. For desktop access through a tunnel, make sure SSH is still running and the local port isn't in use. If SSH works but the desktop is blank, check the graphical session and desktop service.
Include the instance ID, location, model, time and time zone, connection method, full error, and steps you've tried. Mention whether you recently reinstalled the system or changed security settings so support can assess whether the changes are related to the issue.
Cloud Macs from $21.4/day. Choose a model, location, and rental term. Once payment is confirmed and the machine is provisioned, find your credentials in the console. For your first session, verify SSH access before setting up the desktop and development environment.