Unique Credentials
Each order uses separate connection details. Do not reuse the same login materials across teams, projects, or nodes.
AC-01 · UNIQUE
Dedicated Nodes & Responsibilities
One Dedicated Physical Mac per Order
Tenants do not share operating system instances, memory, or local storage. ArmCLI handles physical node delivery, basic connectivity, and platform status records; you handle code, keys, access permissions, business data, and cleanup when you leave.
- 1:1
- Order-to-node mapping
- 99.9%
- Availability target
- 365 days
- Node operates year-round
Node Security Record
AC-NODE-01
Isolation verified
Dedicated physical node; no shared OS instance
- Node ownership
- One active order
- Authentication
- Unique credentials and key-first access
- Status records
- Delivery, session, and resource events
- At expiration
- Access stops and reclamation begins
- Redeployment
- Data handling and status checks completed
The console's real-time status is authoritative for the node state, order ownership, and availability.
Access Control
Make every connection identifiable and revocable
Security does not depend on a single switch. Credentials, keys, permissions, sessions, and incident handling must form a closed loop to reduce the risks of shared passwords, long-lived authorization, and abandoned sessions.
Keys First
SSH automation should use independently revocable keys whenever possible. Keep private keys on controlled devices, never in repositories, build logs, or shared documents.
AC-02 · KEY FIRSTLeast Privilege
Grant only the directory, command, and service permissions required for the task. Use separate identities and working directories for CI runners, interactive development, and operations scripts.
AC-03 · LEASTSign Out
After graphical or command-line work, actively end the session, remove temporary forwarding, and delete local connection records from shared devices.
AC-04 · SIGN OUTRotate Credentials
When a member leaves a team, a device is lost, automation scope changes, or suspicious access appears, revoke old keys immediately and issue new connection materials.
AC-05 · ROTATEHandle Suspicious Access
If you detect an unfamiliar source, unusual command, or unexpected session, disconnect first, revoke credentials, preserve a sanitized timeline, then submit a console ticket.
AC-06 · CONTAIN
Node Lifecycle
Every step, from preparation to reclamation, has a defined status
Physical nodes are never shared between two active orders. State changes are tied to the order, node identifier, and processing record; access and data status are checked again before redeployment.
-
01
Prepare
Verify the model, memory, storage, target location, and basic connectivity, then confirm that the node can enter automated preparation.
-
02
Deliver
Create a one-to-one order-to-node assignment, issue connection details, and require verification of the host fingerprint, tool versions, and disk capacity.
-
03
During-Rental Records
Record node availability, basic connectivity, and resource events without reading user code. You manage project permissions, keys, and business data.
-
04
Reclaim at Expiration
When the rental ends, order access stops and reclamation begins. Back up, migrate, and remove sensitive files before expiration.
-
05
Pre-Redeployment Processing
Process data, invalidate credentials, and recheck node status. The node enters its next delivery cycle only after these checks are complete.
Availability Metrics
99.9% Target verified against service records
Availability is calculated from node status, basic connectivity records, and confirmed events. Effects caused by your local network, actions, software configuration, third-party dependencies, or force majeure are excluded from platform availability.
All nodes operate normally 365 days a year. If an unexpected issue occurs, status records are updated in the order of detection, confirmation, mitigation, recovery, and review.
View Service Terms
Last 90 Days
99.9%
Target
Normal interval
Confirmed event marker
Markers this period: 0
- Measurement unit
- Order-linked node
- Evidence source
- Status and connectivity records
- Compensation handling
- Handled under the service terms and review outcome
Measured Latency Across Five Locations
Check the network path before choosing a location
The table shows median ICMP round-trip latency from the test locations to nodes in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East. These figures compare network paths; they do not represent build speed or remote desktop frame rate.
Test date2026-09-20
Network providerPublic internet via two local fixed-broadband egresses
Sample count20 per path
MethodMedian ICMP RTT, in ms
| Test source | Singapore | Japan (Tokyo) | South Korea (Seoul) | Hong Kong | US East |
|---|---|---|---|---|---|
| Shanghai | 73 ms | 49 ms | 45 ms | 36 ms | 188 ms |
| Taipei | 61 ms | 38 ms | 52 ms | 24 ms | 176 ms |
| Bangkok | 31 ms | 96 ms | 101 ms | 54 ms | 229 ms |
| Sydney | 92 ms | 118 ms | 132 ms | 126 ms | 241 ms |
| Frankfurt | 162 ms | 231 ms | 224 ms | 198 ms | 94 ms |
Measured results vary with your carrier, cross-border routing, wireless network, congestion, and local device. Before ordering, test the target location from your team's main access points; real-time console status is authoritative for actual availability.
Infrastructure Coverage
Five locations cover key Asian routes and the US East
All three available configurations can be deployed in the five locations below. Consider team location, repository routes, dependency sources, and final delivery region together when choosing.
SG
Available
Singapore
Suitable for Southeast Asian teams and build, test, and automation workloads that connect to regional services.
- Check
- Cross-border routing and repository pull time
- Available configurations
- Three plans
JP
Available
Japan (Tokyo)
Suitable for access from Japan and Northeast Asia, and commonly used for interactive development, Xcode builds, and self-hosted runners.
- Check
- Stable latency from your team to Tokyo
- Available configurations
- Three plans
KR
Available
South Korea (Seoul)
Suitable for South Korea and nearby network paths, with a regional option for command-line sessions and continuous integration.
- Check
- Your local carrier's international routing
- Available configurations
- Three plans
HK
Available
Hong Kong
Suitable for teams needing shorter Asian network paths, including remote development, signing, and pipeline execution.
- Check
- Peak-hour path variation
- Available configurations
- Three plans
US-E
Available
US East
Suitable for teams in the eastern US or workloads whose code, artifacts, and automation services are primarily located in North America.
- Check
- Cross-continent dependencies and artifact transfer
- Available configurations
- Three plans
Latency is not a property of one location
Your experience also depends on your local network, carrier routing, VPN, wireless environment, and task protocol. Choose a stable, low-latency path for graphical interfaces; for batch builds, also compare repository and artifact storage locations.
Incident Communication
Unexpected issues are updated in five steps—no vague status in place of conclusions
ArmCLI does not schedule regular downtime. This process covers unexpected connectivity, node, or platform issues; each step updates the known scope, next action, and open questions.
-
01
Detect
Record the first abnormal time, affected nodes, and reproducible symptoms, distinguishing local network signals from node-side signals.
-
02
Confirm
Check status records, basic connectivity, and neighboring node behavior. State the confirmed scope without presenting assumptions as conclusions.
-
03
Mitigate
Prioritize restoring usable connectivity or limiting the spread of impact while recording temporary measures, applicable users, and remaining risks.
-
04
Recover
Verify node connectivity, order ownership, and critical paths. Continue monitoring after recovery rather than closing the incident after one successful probe.
-
05
Review
Compile the timeline, impact scope, trigger conditions, and improvements. Availability and compensation matters are handled under the service terms and review outcome.
Security Feedback
Submit reproducible, sanitized evidence
If you find a potential security issue, first stop tests that could increase the impact. Do not disclose valid credentials, private keys, access tokens, complete host details, or unsanitized logs in public channels.
Include at least
- 01
Reproduction ConditionsDescribe the entry point, initial state, steps to reproduce, and expected result.
- 02
Impact ScopeSpecify whether it affects a single node, the order flow, the connectivity layer, or a public page.
- 03
Time & EnvironmentProvide the time zone, occurrence time, network environment, and client version.
- 04
Sanitized EvidenceAttach an error summary and any necessary screenshots or log excerpts, masking all valid credentials.
General questions are handled in submission order. For ongoing risks, include “Security Issue” in the subject and retain a controlled copy of the original evidence.
Choose the right physical node after reviewing the security boundaries
Three dedicated physical Mac configurations cover Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East. Configuration, node, and actual availability are returned in real time by the console.