RunnerVPS provides cloud Macs running on dedicated Apple Silicon physical nodes—not virtual machines. Choose memory, storage, location, and rental term, then connect via SSH or VNC and validate the toolchain with a minimal task.
From $20.6/dayTwo M4 configurations across 5 locations; actual availability is shown in real time in the console.
Your account, notification email, SSH public key, target Xcode version, and rental term directly affect first access and environment setup. Put them in one internal task brief to make team handoffs clearer.
Create an account with an email the team can access continuously. Existing users should confirm they can enter the console and verify the contact details shown there.
Choose an address that can receive order and device notifications. Avoid using an address owned exclusively by someone who may leave the team.
Prepare the public key generated by your current workstation and record who holds the corresponding private key. Submit only the public key; never send the private key by email, ticket, or repository.
Confirm the target version from the project build settings, dependencies, and existing CI jobs. If the team maintains multiple projects, choose one as the initial validation baseline.
Choose a daily, weekly, monthly, or quarterly term based on task duration. Short compatibility checks usually fit daily or weekly terms; ongoing CI and fixed pipelines are better managed monthly or quarterly.
Record only the owner, target version, public key, and task scope. Share passwords, private keys, signing files, and tokens through your team’s own secrets-management process.
Start with Runner M4 for everyday development, single-project builds, and light automation. Choose Runner M4 Plus for more simultaneous tasks, larger dependency caches, or bigger working sets.
For remote Xcode development, single-project testing, signed builds, and light self-hosted runner workloads.
For parallel workloads, larger caches, multiple build processes, and experimental workflows with higher memory demands.
| Decision factor | Runner M4 | Runner M4 Plus |
|---|---|---|
| Parallel workloads | Single-project builds, testing, and light automation | Multiple build processes or higher concurrency |
| Dependencies and cache | Regular cleanup of dependencies, simulators, and archives | Larger dependency cache and working set required |
| Graphical interface | Remote Xcode, debugging, and standard previews | Remote development alongside more background tasks |
| When to upgrade | Keep using it when memory pressure is stable and disk space is sufficient | Prefer it when frequent swapping or cache cleanup affects tasks |
Prioritize a location near your main operators, code repository, and artifact destination. Both plans cover Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast.
Best for workflows with core collaborators in Southeast Asia or frequent artifact transfers within the region.
Best for teams in Japan and nearby regions that need reliable SSH and graphical access.
Best for development, testing, and build tasks in South Korea and nearby regions, with convenient local device access.
Best for projects collaborating across Asia; use your team’s network paths to assess SSH and file-transfer performance.
Best for projects and pipelines whose collaborators, code services, or artifact workflows are based on the US East Coast.
First test the path from your main operator’s network to the target region, then consider repository pulls and artifact uploads. Do not judge by geography alone or treat a single network fluctuation as a long-term result.
Before confirming, recheck the model, delivery location, start date, rental term, and storage needs. All prices are settled in USD; available payment methods and gateways are shown in the console.
Runner M4 or Runner M4 Plus
Choose one of 5 available locations
Daily, weekly, monthly, or quarterly
Confirm the base SSD covers dependencies, caches, and artifacts
Choose Thunderbolt 5 networking only when your workflow requires it
The actual user should confirm the configuration and location before submission. If the order is tied to a project, record its purpose in your team task system—but never record passwords, private keys, or complete payment credentials.
The goal of the first connection is not to move in every project immediately. First confirm the device identity, access method, system version, and basic network path.
Check the device name, location, access address, and host fingerprint in the console.
Before accepting the host key for the first time, compare every character with the fingerprint shown in the console. Stop and open a ticket if they differ.
Confirm local private-key permissions and use only the registered public key to establish the session.
After signing in, verify the hostname, macOS version, disk space, and current user permissions.
Confirm the target matches the ordered device, then prepare a controlled network or SSH tunnel.
Connect with a team-approved VNC client and adjust the resolution to suit the local display and network.
Check lock-screen, reconnection, and clipboard policies. Avoid storing long-term credentials on shared workstations.
After first validation, immediately update the initial access credentials and assign the least privileges required for each role.
Split setup into five parts: toolchain, repository, signing materials, automation runner, and artifact delivery. Leave reviewable output after each part instead of importing every dependency at once.
Confirm the macOS, Xcode, command-line tools, and project package-manager versions. Record target versions in project documentation or CI configuration so everyone uses the same baseline.
xcodebuild -versionUse a least-privilege deploy key or team-approved access method to clone a test repository. Verify read-only operations first, then add only the permissions required for release.
git remote -vProvide certificates, signing files, and tokens through your team’s own secrets-management process. Never write sensitive materials to repositories, build logs, or ordinary contact email.
security list-keychainsWhen registering the physical node as a self-hosted runner, limit its project scope, use clear labels, and record which team and repository own it.
runner: macos-m4Choose a small test task that completes within minutes to verify dependency resolution, compilation, testing, signing, and the artifact directory. Do not use a full release task as your first attempt.
xcodebuild -showBuildSettingsDefine the archive directory, file naming, verification method, and destination. Confirm artifacts can leave the device before expanding the workload or enabling more projects.
shasum -a 256 artifact.zipThese terms describe device boundaries, access methods, and build workflows. Using the same terminology in task briefs and handoff documents prevents confusion between devices, instances, and runners.
Ending a rental term is more than closing the last terminal window. Recover artifacts first, remove accounts, keys, and project data, then verify the rental status and device association in the console.
Choose Runner M4 or Runner M4 Plus, then select one of 5 locations, a daily, weekly, monthly, or quarterly term, and any required add-ons. Only USDT-TRC20 and Visa / Mastercard / Amex via Stripe are supported; all orders are settled in USD.