ArmMesh provides dedicated Apple silicon servers, not virtual machines. Check the node address and credentials in your order, then connect via a graphical interface or secure terminal, depending on your workflow. For frequent desktop interaction, prioritize round-trip latency; for automation, also consider bandwidth, artifact locations and queue scheduling.
Six available locations: Singapore, Tokyo, Seoul, Hong Kong, the US East Coast and the US West Coast. The console provides the current address, port and availability in real time.
≤60 ms is better for sustained graphical interaction. Cross-continent connections work for code sync, CI/CD scheduling and MLX API calls, but are less suited to frequent desktop interaction.
Connection failures rarely have a single cause. Before changing local settings, verify your order, address, credentials, network and client version to avoid mistaking incorrect node details for a client issue.
Sign in to the console and confirm your order has been provisioned. Note the model, location and current node ID. Orders still being processed may not have complete connection details, so don't keep trying an old address.
Check the host address, connection protocol and port returned by the console character by character. Don't guess connection settings based on another order, an old support ticket or a teammate's saved details.
Make sure the username, initial credentials and key belong to the current node. Change the initial credentials immediately after connecting, then use a managed key for ongoing access.
Confirm your local network allows outbound traffic on the target port. Disable any temporary proxy that changes routing, then test again. On a corporate network, check firewall rules and your outbound IP first.
Use a supported client release and check the compatibility range in your order details. Save your current settings before upgrading so you can identify any differences in scaling, keyboard input or authentication.
Don't share node credentials, full host addresses or private keys in chat logs, public build logs or code repositories. When collaborating, share only the minimum information needed for the task.
A graphical session works well for Xcode debugging, signing setup, UI checks and occasional manual tasks. Run continuous builds and batch jobs as terminal tasks instead of relying on a desktop session to keep them running.
Copy the current node address and port from the console, then create a new connection in a supported graphical client. Before your first authentication, check the node location and username again to avoid sending credentials to the wrong address.
Done when: The desktop has loaded fully, and the menu bar and pointer respond as expected.Start with the resolution recommended by your client to establish a stable session, then adjust scaling to suit your local display. On high-latency networks, lower the resolution and animation quality first; don't increase color depth and frame rate at the same time.
Done when: Text is clear and windows move without persistent lag.Enable clipboard sync only when you need to transfer code or commands. Never share content containing keys, tokens or signing materials via the shared clipboard; import it through a controlled file path with restricted permissions.
Done when: Text copies as expected and sensitive content isn't retained in sync history.Test Command, Option, Control, function keys and input-source switching. If the local and remote layouts differ, fix the mapping in the client first, then configure IDE shortcuts.
Done when: Common shortcuts, stop keys and input-source switching work consistently.Check the status of builds, uploads and model processes before disconnecting the graphical session. Move tasks that need to keep running into a managed background process. When finished, quit the client and clear sensitive details from its local connection history.
Done when: The session is disconnected and background tasks are tracked separately.Secure terminal access is ideal for code sync, CI/CD runners, log collection, artifact transfers and MLX service management. Verify the host identity first, then manage keys, permissions and session persistence separately.
Use separate keys for personal access, CI runners and temporary troubleshooting. Keep an independent revocation path for each use, and never copy the same private key across devices.
Use the node details in the console to verify the address, port and fingerprint. If the fingerprint doesn't match, stop and open a support ticket to confirm the node change.
Run long builds, downloads, model loading and load tests in resumable sessions. Record the startup command, process ID, log path and stop procedure.
Limit key usage and account access; remove public keys you no longer use. Use a dedicated runner account for shared pipelines, separate from accounts used for manual work.
Use the table to shortlist locations, not as a substitute for testing from your own network. Graphical interaction is usually more sensitive to latency; code sync, artifact uploads and model transfers also depend on bandwidth, packet loss and data source location.
| Access city | Singapore SG |
Tokyo, Japan JP |
Seoul, South Korea KR |
Hong Kong HK |
US East US-E |
US West US-W |
|---|---|---|---|---|---|---|
| Singapore | 18 ms | 74 ms | 79 ms | 38 ms | 238 ms | 169 ms |
| Tokyo | 76 ms | 12 ms | 37 ms | 49 ms | 171 ms | 108 ms |
| Seoul | 82 ms | 34 ms | 11 ms | 45 ms | 188 ms | 121 ms |
| Hong Kong | 39 ms | 51 ms | 48 ms | 10 ms | 218 ms | 148 ms |
| New York | 241 ms | 176 ms | 190 ms | 221 ms | 24 ms | 78 ms |
| Los Angeles | 171 ms | 109 ms | 123 ms | 151 ms | 79 ms | 21 ms |
| Frankfurt | 164 ms | 231 ms | 244 ms | 189 ms | 92 ms | 158 ms |
Results vary with carrier routing, wireless conditions, international links and local egress. Before ordering, test candidate locations repeatedly from your actual office network and consider where your code repository, object storage and team members are located.
Don't choose a location based solely on the lowest single ping. Consider where people work, where code and artifacts are stored, and how tasks run to find the node that shortens your end-to-end workflow.
Mouse movement, window dragging, UI debugging and editor input are all affected by round-trip time. Choose the closest node with stable routing, then adjust resolution and image quality.
The number of small files, repository location and dependency cache hit rate often matter more than a single ping. Keep the node close to your repository or mirror, and avoid repeatedly fetching all dependencies.
Triggers usually send only a small amount of control data, so ongoing latency has limited impact. Focus instead on runner concurrency, queue wait time, cache directories and complete failure logs.
Large archives, video assets and model files depend more on sustained bandwidth and stability. Choose a node close to artifact storage and use transfers that support verification and resuming.
Short requests are more sensitive to network round trips, while long inference jobs depend more on the model, context and concurrency. For cross-continent calls, reuse connections and avoid unnecessary serial requests.
Dedicated physical machines provide fixed hardware resources, but you remain responsible for accounts, keys, project files and access. Set your security baseline on first connection and review it whenever team members or tasks change.
Change the initial credentials immediately after your first login, confirm the old value no longer works and save the new one in your team's approved secure storage.
First connectionSet up separate keys for personal access and automation runners. Never share a private key between uses, so each can be revoked and audited independently.
Separate by useAvoid having multiple people use the same account for manual work. When handing off a task, record its status and artifact location instead of sharing personal credentials.
Track accessGive access to keys, signing certificates, environment files and project tokens only to the accounts that need them. Don't print sensitive values in build logs.
Least privilegeWhen someone leaves a project, an automation job is retired or a device is replaced, promptly remove the associated public key and access permissions, and record the action.
Review regularlyExit elevated contexts, check task status, disconnect graphical and terminal sessions, and clear local connection history from unmanaged devices.
Every time you leaveChange one variable at a time. Test a single hypothesis at each step and record the time, symptoms and outcome. When you open a support ticket, this helps rule out anything you've already verified.
Confirm other network services are working. Switch to a wired or backup network and test again; pause any proxy that changes routing. Note whether the issue occurs only on the current network.
Expected result: Stable access to the target network with no sustained packet loss.Copy the current node address, protocol and port from the console again. Don't use browser autofill, old bookmarks or connection details from another order.
Expected result: The connection target matches the current order, location and protocol exactly.Check that the username, password or key file belongs to the current node, and that the private key permissions match the identity selected in your client. Don't repeatedly submit incorrect credentials.
Expected result: Authentication succeeds, or returns a clear error you can record.Check the instance status and latest events in the console to distinguish a connection issue from a problem with a process on the node. The console's real-time status is the source of truth for availability.
Expected result: The node is healthy, with no pending power or system operations.Check the protocol, scaling, keyboard mapping, proxy, certificates and cached host fingerprints. If needed, create a new connection without inheriting old settings and compare the results.
Expected result: The default settings connect, or the issue is narrowed down to a specific client setting.Include the order number, node location, macOS version, time of issue, protocol, client version, reproduction steps and redacted logs. Never submit passwords, private keys or full tokens.
Expected result: Support can reproduce the issue from the timeline without repeatedly asking for basic details.If you still can't connect after these six steps, sign in to the console and open a support ticket. For general questions, email us at support@armmesh.com.
ArmMesh offers two dedicated physical machine tiers: ArmMesh M4 and ArmMesh M4 Pro, available in Singapore, Tokyo, Seoul, Hong Kong, the US East Coast and the US West Coast. Starting at $19.5/day. Check real-time availability in the console.