Connect. Migrate. Build.

On your first connection, check the host fingerprint and accept it only after confirming it matches trusted instance details. Don’t disable host key checking just to skip the prompt.

ssh admin@<node address>

If your instance uses a non-default SSH port, add -p <port> to the command. After logging in, run these checks to confirm the current user, macOS version, and available disk space.

whoami
sw_vers
df -h
passwd

passwd interactively changes the current user’s password. Next, generate a dedicated ed25519 key on your local machine and append its public key to the node’s ~/.ssh/authorized_keys. Keep the private key on your own device or in a controlled key store.

ssh-keygen -t ed25519
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Run the permission commands on the node. Test key-based login in a second terminal before adjusting password authentication to match your team’s security policy. Make sure you don’t lock yourself out.

Use the Screen Sharing details in your instance information when you need to manage Keychain, check Xcode settings, or use the Simulator. The connection address and port may differ from SSH, so don’t assume they’re the same.

1. Confirm the instance is ready, then get the Screen Sharing address, port, and user details from the console.
2. Connect using the Screen Sharing app on your local Mac and sign in with the supplied account credentials.
3. After reaching the desktop for the first time, change the initial password and check that the login keychain unlocks correctly.
4. Open the Xcode version you need, accept the licence, install any required components, then verify the setup from the command line.

xcode-select -p
xcodebuild -version

If you connect to Screen Sharing through an SSH tunnel, use the forwarding and destination ports configured for your instance. Restrict access to trusted sources; don’t expose the desktop port to everyone.

A black screen doesn’t necessarily mean the node is offline. First check reachability over SSH, then check the graphical session, account permissions, and connection port. Don’t keep resetting the system to troubleshoot.

Automated app builds

First check that the scheme is shared, signing is configured correctly, and the keychain is accessible. If the project has a Gemfile, use Bundler to pin the Fastlane version, then create an archive.

bundle install
bundle exec fastlane gym
bundle exec fastlane pilot upload \
  --ipa ./build/App.ipa

Replace the example path with the actual artifact path. Before using pilot to upload, configure the release API key required by your project and store it in a protected CI variable. Upload permissions and build success are separate checks.

Remote Mac development

Verify a standard SSH connection first, then configure VS Code Remote-SSH to use the same connection details. If the editor can’t connect, check the remote extension logs before changing system permissions.

Host sdk-build
  HostName <node address>
  User admin
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30

Save this in your local ~/.ssh/config. After connecting, check which machine your terminal is on and confirm the working directory. Use Screen Sharing for the Simulator and graphical debugging; SSH is enough for editing code and using Git.

GPU rendering and MLX inference

First confirm that your workload supports Apple Silicon and the required graphics backend, then set up an isolated Python environment. Leave room for model weights, application memory, and intermediate results.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx
python -c "import mlx.core as mx; print(mx.default_device())"

Start with a small input to verify dependencies and device selection, then gradually increase resolution, batch size, or context length. Record the application version and parameters. Whether a specific model will run depends on its weight size and actual memory use.