Remote session path

Connect to your Cloud Mac, from credentials to a stable session

Verify the node and access source in the console, prepare your username and key, then choose SSH, a graphical desktop, or an automated session for your task. Each NowMini order provides one dedicated M4 physical machine—not a virtual machine.

Manage nodes in the console View the support guide
Connection stages
3 stepsto complete your first session
Node coverage
4Asian nodes available
Uptime
365 daysof normal operation
Pre-connection checks

Rule out environmental differences before opening the client

These six details must come from the same order and the same node. Do not mix an old node address, another member’s username, or a previous key into this connection.

A1

Order and node status

Confirm in the console that the order is ready for use, then verify the current node identifier. The console’s live response is the source of truth for availability.

Acceptance: order and node identifiers match
A2

Node region

The available regions are Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Confirm that the connection details match the selected region; do not use another node’s address.

Acceptance: region matches the order record
A3

Username and credentials

Check the username, key file, and credential validity scope character by character. Store the private key only on a controlled device; never send it through chat or a code repository.

Acceptance: credentials belong to the current user
A4

Access source

Check whether the current public egress address or team gateway meets the node’s source restrictions. After changing networks, verify again whether the egress address has changed.

Acceptance: current source is permitted
A5

Local network

First rule out the effects of proxies, corporate firewalls, public Wi-Fi, and unstable routing. If needed, cross-check with another trusted network.

Acceptance: connection to the target port succeeds
A6

Client version

Record the SSH or graphical client name and version, along with the local operating system version. Team members should use consistent connection parameters to reduce client differences.

Acceptance: version and parameters recorded
Shell session

Establish your first verifiable connection with SSH

The host address, username, and key file in these commands are placeholders. Copy the current node details from the console before running them; do not copy the example values verbatim.

STEP 01

Restrict local key permissions

First confirm that the file belongs to the current local user, then prevent other accounts from reading it. The key filename should distinguish environments but must not contain a real password or token.

STEP 02

Start an SSH session

Specify the key, username, and host address explicitly. During initial troubleshooting, keep the client output visible instead of masking the source of errors with numerous hidden parameters.

STEP 03

Verify the host fingerprint on first connection

The fingerprint shown on first connection must match the information provided in the console. If a previously used address with the same name has a different fingerprint, stop and verify the node record.

STEP 04

Complete the session check

After logging in, verify the hostname, current user, working directory, and available disk space. Do not import code, certificates, or model files into a session whose identity has not been confirmed.

SSH connection record PLACEHOLDER VALUES
Restrict key permissions 
chmod 600 ~/.ssh/<KEY_FILE>
Start a connection 
ssh -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
Show detailed diagnostics 
ssh -vv -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
Verify identity in the session 
hostname
whoami
pwd
df -h
First-connection principle Verify the fingerprint before accepting it
Graphical desktop

Check the display, input, and reconnection separately

A graphical session is ideal for Xcode, Logic Pro, and tasks that require window interaction. A successful connection does not guarantee a stable experience: validate resolution, keyboard input, and clipboard access separately.

  1. 01

    Start a session

    Get the current node’s graphical connection details from the console and verify the host address, username, and access source. Keep the default image quality for the first session and confirm stable access to the macOS graphical interface.

    Result: desktop visible and input working
  2. 02

    Adjust the resolution

    Adjust it gradually based on your local display and link quality. Higher resolution increases bandwidth and encoding load; if stuttering persists, reduce the image size first, then assess whether the node is the issue.

    Result: text is clear and interaction remains smooth
  3. 03

    Calibrate the keyboard layout

    Check language switching, Command, Option, Control, function keys, and common shortcuts. Mappings may differ between local systems, so document the team’s standard key mapping.

    Result: shortcuts behave as expected
  4. 04

    Verify the clipboard

    Start by testing one-way and two-way copying with a short text containing no sensitive information. Never transfer private keys, complete tokens, or unredacted production data through the clipboard.

    Result: permitted text transfers in a controlled manner
  5. 05

    Handle disconnections and reconnections

    First determine whether the local network changed, then check the access source, client logs, and node status. Before reconnecting, avoid creating several duplicate sessions in succession, which can make desktop responses misleading.

    Result: return to the original task context
File and code synchronization

Choose the transfer path by content type

Source code, temporary files, and build artifacts should not share one synchronization method. Define the data source, destination, and retention period first, then choose Git, secure file transfer, or artifact download.

Uses, operating boundaries, and acceptance criteria for three synchronization paths
Path Suitable content Execution method Security boundary Acceptance result
Git pull Version-controlled source code, scripts, and configuration templates Clone or pull into a dedicated working directory, pin the branch and commit, and record the dependency lockfile Do not store private keys, tokens, signing materials, or local credential files in the repository Commit hash matches the pipeline expectation
Secure file transfer Model files, assets, temporary data, and inputs unsuitable for repository storage Transfer with a controlled account to a defined destination directory, then verify file count, size, and checksums Open only the required directories; assign an owner and cleanup time for temporary files Files are complete and permissions match their purpose
Artifact download Archives, logs, test reports, symbol files, and deliverable packages Download from the output directory after the task, naming files with the task ID, commit hash, and build number Before downloading, check that artifacts contain no environment variables, credential fragments, or unredacted logs Artifact is traceable to one unique task

Secure copy command structure

Suitable for a single file or small directory. The host, user, key, and paths below are placeholders.

scp -i ~/.ssh/<KEY_FILE> <LOCAL_FILE> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>

Incremental synchronization command structure

Suitable for repeatable directory transfers. Before running commands with deletion options in production, use preview mode to inspect the scope of changes.

rsync -av --dry-run -e "ssh -i ~/.ssh/<KEY_FILE>" <LOCAL_PATH> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>
Automation integration

Make your CI runner executable and auditable

An automation account should not be reused as a daily interactive account. Manage identity, keys, working directories, caches, and logs separately so failures can be traced to a specific task, permission, or input.

RUNNER-01

Use a dedicated account

Create a dedicated system account for the runner with automation-only responsibilities. Keep interactive development, graphical sessions, and pipeline execution under separate identity boundaries.

  • Account name maps to one unique pipeline purpose
  • Do not share authentication materials with individual team members
  • Revoke the account’s permissions when disabling the runner
KEY-02

Configure least-privilege keys

Grant keys only the login and directory permissions required by the task. Use separate keys for different repositories, teams, or environments to limit the impact of a disclosure.

  • Key purpose and owner are traceable
  • Do not write private keys to repositories or build logs
  • Regularly verify unused keys and revoke them
PATH-03

Use fixed working directories

Place source code, caches, temporary files, and artifacts in separate fixed directories. Clear mutable state before each task and retain only necessary records afterward.

  • Each pipeline uses a clearly defined root directory
  • Caches may be reused but must not cross permission boundaries
  • Keep artifact and source directories separate
LOG-04

Keep auditable logs

Record the task ID, commit hash, start and end times, exit code, and artifact location. Redact any credential-related fields in logs.

  • Failed tasks retain complete stage boundaries
  • Record client and runner versions
  • Logs can be linked to one unique order and node
Connection troubleshooting

Locate the failure layer by layer, from local network to node

Do not change the network, address, key, and client parameters at the same time. Validate one layer at a time and record the result to distinguish local issues, access restrictions, authentication errors, and service status.

  1. 1

    Check the local network

    Confirm that the device can access the network normally, disable any temporary proxy that may rewrite routes, and try again. Cross-check with another trusted network to determine whether the issue follows the current egress.

    Evidence: network and egress address
  2. 2

    Check the access source

    Compare the permitted source in the console with the current public egress. The egress address may differ after switching between a corporate network, mobile hotspot, and home network.

    Evidence: source restriction record
  3. 3

    Check credential permissions

    Confirm that the username belongs to the current node, the private-key path is correct, and local file permissions are sufficiently restrictive. After an authentication failure, do not repeatedly try unrelated keys.

    Evidence: authentication-stage output
  4. 4

    Check the host address

    Copy the address again from the console and rule out an old record, spaces, missing characters, or a mixed-up node. If you use a configuration alias, also check its expanded real value.

    Evidence: target address for this session
  5. 5

    Check the service status

    Return to the console and verify the live response for the order, node, and connection service. Do not infer node status solely from a generic local-client error.

    Evidence: live console result
  6. 6

    Read the client logs

    Record whether the failure occurred while resolving the address, establishing the network connection, negotiating the protocol, verifying identity, or entering the session. Remove credentials and sensitive paths before submitting a support request.

    Evidence: redacted client logs

Still unable to connect

Submit a support ticket through the console with the order identifier, node region, incident time, reproduction steps, client version, and redacted logs. If you have not placed an order, use the contact page to describe your target workflow and preferred region.

Submit a console support ticket Contact the team
Secure session cleanup

Reclaim access and temporary data when the task ends

Closing the window is only part of ending a session. Resolve temporary credentials, caches, transferred files, and team-member permissions explicitly.

Exit the remote session

Finish running commands and graphical applications normally, then exit the SSH or graphical session. Confirm that no leftover interactive process is using the working directory or output files.

Completion marker: session clearly ended

Revoke temporary credentials

Delete temporary keys, tokens, and account authorizations created only for this task. After revocation, run a verification to confirm that the old credentials can no longer access the node.

Completion marker: temporary access is invalid

Clean up cached files

Separate reusable build caches, task temporary files, and sensitive inputs. Keep only content with a defined purpose and retention period; clean up the rest according to the task checklist.

Completion marker: directory matches retention rules

Handle team-member changes

When a team member leaves the project or changes responsibilities, rotate access keys, remove old account permissions, and check whether runners, scripts, or local configuration still reference old credentials.

Completion marker: members and permissions remapped
Final records

Keep results, not secrets

You may record the task ID, commit hash, artifact location, exit code, owner, and completion time. Do not put passwords, private keys, complete tokens, or sensitive business data in acceptance records.

Prepare the node details before connecting

Confirm the order, region, host address, and credentials in the console first. Need a new node? Rent a NowMini M4 with M4, 16GB RAM, and 256GB SSD—a dedicated physical machine, not a virtual machine.

Rent a Mac mini M4 now View frequently asked questions