Use VNC for the desktop, macOS Screen Sharing on a Mac, and SSH for commands, file transfers, or CI. First, get the current connection details for your node in the console, then follow the steps for your computer.
Already ordered? You won’t need to enter your password on this page. Use the connection address, port, and username shown in your instance details after signing in.
Use a graphical desktop to interact with the Mac and the command line to automate tasks. Both connect to the same dedicated physical machine, not a separate virtual machine.
Ideal for initial setup, working in Xcode, checking build results, and tasks that need a mouse. Windows and Linux users can start here.
You’ll need a compatible VNC client and the desktop address, port, and authentication details from the console. Check the client’s encryption prompts when connecting.
Choose this to access the macOS desktopIdeal if you’re using a Mac locally. Open the built-in connection option from Finder—no need to install another desktop client first.
You’ll need the VNC connection details from the console. System Screen Sharing and third-party clients may prompt for authentication differently; follow the prompts you see.
Built-in access from a local MacIdeal for Git, installing dependencies, syncing files, and self-hosted runners. Background builds don’t need a continuous desktop stream.
You’ll need the SSH address, username, port, and password or key. Verify the host fingerprint on first connection, then set up key-based login.
Best for automation and low-bandwidth tasksThe interface examples below show where to click; they don’t contain real addresses, account names, or passwords. Button labels may vary slightly by system version. Always use the values shown in the console.
Use macOS Screen Sharing to connect from the server address to the desktop.
Sign in to the console and open your instance details. Copy the VNC address and port, and note the authentication method. Don’t enter the SSH port in the desktop connection field.
In Finder, choose “Go” → “Connect to Server,” or press ⌘ + K. Enter the address in the format vnc://host:port ; if the console provides a complete connection address, use it as is—don’t add the prefix again.
vnc://host:portEnter the desktop authentication details when prompted. If the macOS login screen appears next, enter the system username and password. Once the desktop loads, open a regular app and check that the mouse and keyboard work before adjusting the resolution.
Use a VNC client that supports your node’s authentication method. You don’t need to create a separate remote-device account.
Install RealVNC Viewer or TigerVNC Viewer, and make sure the client version supports your system. Then get your instance connection details from the console. Don’t use the examples in this guide as real credentials.
Enter the address in the address bar or a new connection. RealVNC commonly uses host:port; for an explicit TCP port, TigerVNC commonly uses host::port. Follow the client’s field instructions so the port isn’t mistaken for a display number.
Check the target address before entering your authentication details. If the client warns that the connection is unencrypted, don’t ignore it. Check the node’s connection instructions and use an SSH tunnel if needed. Once connected, test letters, symbols, and keyboard shortcuts.
Save the address and display preferences in a connection profile. Whether to save the password depends on your local device security policy.
Install Remmina and the VNC protocol plugin, then create a new connection. If VNC isn’t listed, check that the plugin is fully installed. Don’t use RDP to connect to the same address.
Enter the address and port shown in the console in the Server field. Choose the authentication method specified in the node’s connection instructions. If only a VNC password is required, don’t enter a system username in an unrelated field.
Sign in once with the default display settings, then adjust scaling, color depth, or clipboard options. If your local client captures remote-session shortcuts, learn how to release them so you can switch back to your local desktop in full-screen mode.
Remote desktop performance depends on round-trip latency, bandwidth, packet loss, and encoding overhead. These are starting points, not performance guarantees. Change one setting at a time, then compare by dragging a window or typing in the same window.
| Workload | Suggested starting resolution | Color depth and compression | What to check |
|---|---|---|---|
| Toolchain setup and everyday input | 1440 × 900 | Try 24-bit color first if supported by your client; leave encoding on auto. | Check that text is clear and the cursor responds smoothly before scaling up the desktop. |
| Xcode and multiple windows | 1920 × 1080 | Prefer 24-bit color; increase compression if bandwidth is limited. | Distinguish local display scaling from the remote resolution to avoid making text too small twice. |
| Mobile or low-bandwidth networks | 1280 × 800 | Try 16-bit color and higher compression if supported. | Turn off high-frame-rate content first. Switch back to higher color depth for color-critical work. |
| Long builds and CI | No need to keep the desktop open | Use SSH to check logs, and run builds as a separate task or runner service. | Make sure the task doesn’t depend on the current interactive session before disconnecting the desktop. |
The five node locations are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the eastern United States. Start with the location closest to the person doing the work. For teams across time zones, prioritize the person who interacts with the node most often. Distance is only a starting point—your ISP’s routing and actual connection experience matter too.
Higher resolutions send more pixels. Higher compression can reduce traffic, but may increase encoding overhead or reduce detail. Start by turning off dynamic wallpapers, video previews, and unused windows, then adjust settings gradually. Scaling the display alone usually won’t reduce the number of pixels sent from the remote machine.
You have exclusive use of the entire Mac mini for the rental period. The connection address isn’t an access control. Protect your passwords, keys, and local device too.
After signing in to macOS, change the system account password. If the desktop service uses a separate VNC password, check and update that too; the two passwords may not sync automatically.
Keep your current session open after changing the password. Test the new password in a second connection, then close the old session. Don’t change the password, network, and sharing settings all at once.
Change one thing, then verify itGenerate a passphrase-protected key pair locally, then add only the public key to the remote account’s authorized keys. Keep your private key local—never send it in a support ticket or commit it to a repository.
First, verify that you can sign in from a new terminal with the key. Then decide whether to restrict password authentication. Each team member should use their own key; revoke it separately when they leave the team.
Verify first, then tighten authenticationCheck your system sharing settings and keep only the services you actually use, such as Screen Sharing, Remote Login, or File Sharing. Limit which users can sign in; don’t open services to every account.
Before turning off Screen Sharing, confirm SSH works. Before changing SSH, keep a verified desktop connection available. Don’t disable both recovery options at once.
Always keep one working connection methodFirst check the instance status and connection details in the console. Then distinguish between a network issue, authentication failure, and a desktop display issue. Repeatedly trying the password won’t fix a port or routing problem.
Wait for the current system session to finish loading, then disconnect and reconnect once. Try disabling hardware acceleration in the client or switching to the default encoding to rule out a client display issue. If SSH works, the node is still reachable; check the system session and Screen Sharing settings next.
Don’t force a restart right away—you could interrupt a build or lose unsaved files. If the screen is still blank, include the client name and version, an error screenshot, and the node ID in your support ticket. Hide the password and full connection address in the screenshot.
First lower the remote resolution, stop video and other motion, then check whether a large file is uploading locally. Compare with SSH response times: if the command line is slow too, check routing, packet loss, or your local network. If only the desktop is slow, adjust encoding, color depth, and resolution.
Note when it happened, your local network type, and what changed after each adjustment. If you need to switch nodes, ask about migration first; switching nodes won’t automatically move all your projects and caches.
First align the local and remote keyboard layouts and input methods. Test letters, numbers, and symbols in a plain text editor, then check the client’s shortcut forwarding, Command mapping, and full-screen key capture settings.
Ctrl and Alt on Windows or Linux may not map to macOS the way you expect. Test individual keys first, then key combinations. Don’t repeatedly test keys in a password field.
Check that the client allows clipboard sync in both directions, then test with a short plain-text snippet. If text syncs but images or files don’t, the client may support different formats; that doesn’t mean the connection is broken.
Use SFTP or rsync to transfer files instead of relying on desktop copy and paste. If clipboard sync still fails after reconnecting, temporarily turn the client’s clipboard option off and back on. Don’t copy keys, tokens, or passwords into unrelated apps to test it.
For “Connection refused,” check the SSH address and port, then confirm Remote Login is enabled. For a timeout, check network reachability. Check the username, password, or public key only if authentication fails.
If the host fingerprint changes, stop and confirm through a console support ticket whether the node has been re-provisioned. Don’t delete the known-host entry to bypass the warning or disable host key checking.
Next, follow the CI integration guide: register a self-hosted runner, check the toolchain and working directory, run it manually once, then switch to the pipeline label. Don’t have a node yet? Rent a dedicated physical M4 Mac.