ArmVMS offers 5 nodes in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the Eastern US. Each order maps to one dedicated Apple Silicon physical machine with no shared compute resources—and it is not a virtual machine.
JPJapan (Tokyo)Japan and Northeast Asia teamsAvailable
KRSouth Korea (Seoul)Local collaboration path in South KoreaAvailable
HKHong KongCross-region collaboration in AsiaAvailable
US-EEastern USEastern North America workloadsAvailable
Node Map Overview
Five regions make up the fixed availability directory
The map marks only the five nodes currently offered by ArmVMS. It does not split cities or add regions outside the directory. Before choosing, identify the primary access path between developers, code sources, and dependent services, then confirm live availability in the console.
SGJPKRHKUS-EAST
Asian nodesSingapore, Japan (Tokyo), South Korea (Seoul), Hong Kong
North American nodeEastern US
Selection principleConsider team location, code source location, and the scope of collaboration
Regional Directory
Check each node instead of relying on map distance alone
A shorter network path does not mean every dependency is closer. Continuous integration also accesses code repositories, package indexes, artifact storage, and team collaboration systems, so choose a node based on the complete data path.
SGAvailable
Singapore
Best for projects whose team members, code sources, or dependency download paths are mainly in Southeast Asia. For cross-border collaboration, also check where build artifacts are ultimately delivered rather than choosing solely by the developer's current location.
Best for workloads whose developers and project collaboration resources are mainly in Japan or Northeast Asia. For frequent remote graphics operations, test the stability and interactive latency from the local network to Tokyo first.
Check
Graphics session and code pull paths
Common workloads
Xcode development, build archiving, UI validation
Available configurations
ArmVMS M4, ArmVMS M4 Pro
KRAvailable
South Korea (Seoul)
Best for projects whose team members or CI schedulers are mainly in South Korea. If tasks repeatedly download large dependencies, compare the actual transfer path between the Seoul node and the dependency source first.
Best for teams with collaborators across multiple Asian regions that need a unified access point. Before choosing, identify where code, build caches, model files, and final artifacts enter and leave the node.
Check
Shared access path for cross-region team members
Common workloads
Remote development, build coordination, AI experiments
Available configurations
ArmVMS M4, ArmVMS M4 Pro
US-EAvailable
Eastern US
Best for tasks whose teams, code sources, or automation systems are mainly in Eastern North America. If team members in Asia need frequent access to a graphical desktop, compare the interactive path before ordering and consider separating automated tasks from manual operations.
Check
North American code sources and team collaboration scope
ArmVMS M4 and ArmVMS M4 Pro are available in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the Eastern US. “Available” in the matrix means the combination is part of the regularly orderable directory; it does not reserve a specific device in advance.
Availability of ArmVMS's two Apple Silicon physical machine plans across five nodes
Model and specifications
Singapore
Japan (Tokyo)
South Korea (Seoul)
Hong Kong
Eastern US
ArmVMS M4M4 · 16GB · 256GB SSD
Available
Available
Available
Available
Available
ArmVMS M4 ProM4 Pro · 64GB · 2TB SSD
Available
Available
Available
Available
Available
Configuration 01
ArmVMS M4
M4 with 16GB of memory and a 256GB SSD, suited to everyday development, lightweight builds, UI validation, and short automation tasks. When choosing a node, prioritize the developers who need frequent interaction.
Configuration 02
ArmVMS M4 Pro
M4 Pro with 64GB of memory and a 2TB SSD, suited to large projects, parallel builds, larger model files, and long-running tasks. Also consider the transfer direction of datasets and build artifacts when choosing a node.
Node Selection Method
Map the access paths before choosing a point on the map
Node selection is not simply about the distance from developers to the data center. A complete task typically includes five paths: user access, code retrieval, dependency downloads, build execution, and artifact export. Prioritize the path that occurs most often and has the greatest impact on delivery.
01
Map team members and automation entry points
Record where members who need a graphical interface are located, where command-line operations originate, and where the CI/CD scheduler is based. When manual interaction is frequent, the team-to-node path usually matters more than a single artifact download.
Input
Member locations, runner locations
Output
Primary access direction
02
Check code sources and dependency locations
List the locations of code repositories, package indexes, binary dependencies, model files, and artifact storage. When builds frequently pull large files, the dependency path may affect total time more than the desktop interaction path.
Input
Repository, dependency, model, and artifact locations
Output
Primary data flow
03
Confirm live availability against the task cycle
After determining the configuration and rental term, check the target node's live result in the console. Add physical nodes for short-term peaks; for long-term fixed workloads, also evaluate migration frequency and data management costs.
Input
Configuration, rental term, target node
Output
Actionable order selection
Migration Preparation Checklist
Before changing nodes, handle migratable content separately from sensitive credentials
Migration is not about copying the entire old environment. The goal is a deployment process that can be verified, rolled back, and repeated. Organize project data first, then handle credentials separately to reduce omissions and the risk of sensitive information entering logs or archive files.
Code repository
Confirm the default branch, unpushed commits, submodules, generation scripts, and repository access method. Before migration, ensure critical changes are recorded in a traceable version history.
Acceptance: the new node completes a clean checkout
Dependency cache
Separate caches that can be downloaded again from internal dependencies that must be retained. Record package manager versions, lockfiles, and cache directories; do not carry damaged caches to the new node unchanged.
Acceptance: dependencies restore at locked versions
Access credentials
List repository keys, automation tokens, and service access permissions, then reconfigure them through a secure process during migration. Do not put passwords, private keys, or tokens in scripts, archives, or ticket bodies.
Acceptance: expired credentials have been removed
Build artifacts
Separate reproducible intermediate files from deliverables that need to be archived. Retain version numbers, build parameters, verification data, and export locations so artifact provenance remains clear after migration.
Acceptance: critical artifacts are traceable
Model files
Record model versions, file sizes, shard structures, and checksums. Plan transfer order and temporary storage separately for large files so they do not fill the disk alongside build caches.
Acceptance: model file checksums match
Migration validation
Before cleaning up the old environment, complete and verify a code checkout, dependency installation, build, artifact export, and connection. Record the node, configuration, and error logs so issues can be traced back to a clear step.
Acceptance: the complete task has been successfully reproduced
Prepare to create a node order
Choose one dedicated physical machine from 5 nodes
Open the console to check live availability, choose ArmVMS M4 or ArmVMS M4 Pro, verify the node, rental term, and add-ons, then create the order.