Developer infrastructure team

Give every recurring build a clearly assigned cloud Mac

RunnerVM provides dedicated physical Mac mini nodes for iOS, macOS, CI/CD, and AI experiments. We never present shared virtual resources as dedicated devices; we clearly list models, locations, prices, delivery status, and support paths.

1 available configuration
5 nodes or data centers
365 days normal node operation
Rent Runner M4 now View configurations and pricing
RUNNERVM Build job run sheet
Physical node
Code commit Dedicated Mac Build artifact
Available model
Runner M4
Hardware
M4 / 16GB / 256GB
Device type
Dedicated physical machine, not a virtual machine
Available locations
Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, US East
Verifiable configuration Trackable order Traceable incidents
Our origin

RunnerVM began with one build pipeline that runs again and again

Mobile app builds are not one-off remote operations. Code checkout, dependency restoration, signing-material injection, archiving, exporting, and log retention happen continuously. Teams need a reusable execution environment with clear ownership.

We started by solving where builds run

A local development machine is ideal for interactive work, but not always for long-running, repeatable automation. RunnerVM provides a dedicated physical Mac mini as infrastructure you can rent by term, so teams can manage build scripts, caches, toolchains, and artifact paths continuously.

The service is not about moving a desktop into a browser. It provides a cloud Mac that works through a graphical interface or command line. Developers can run Xcode, xcodebuild, fastlane, testing tools, and common dependency-management workflows as their projects require.

01

Identify repeatable tasks

Move recurring signing, archiving, exporting, and log collection off personal devices.

02

Standardize the environment

Keep toolchains, caches, and build directories manageable on a dedicated physical node.

03

Keep a verification trail

Track configurations, orders, nodes, tickets, and run records through one connected workflow.

Service boundaries

Which tasks belong on RunnerVM—and which decisions remain with your team

Clear boundaries matter more than labeling every problem a cloud-service capability. We provide the execution environment and node management; your team owns project architecture, signing strategy, dependency versions, and release decisions.

Built for continuous builds and remote development

For iOS and macOS compilation, CI/CD runners, React Native iOS builds, automated Xcode archiving, command-line tasks, remote debugging preparation, and AI experiments that specifically require Apple Silicon.

  • Need a dedicated compute environment and stable directory structure
  • Need to use a device by day, week, month, or quarter
  • Need to choose an access location from five available regions

We never label shared resources as dedicated devices

RunnerVM offers dedicated physical Mac mini devices, delivered as non-virtual machines. The site does not replace real models with vague “high-performance instances” or advertise memory, storage, or chip combinations outside the catalog.

  • We do not choose project dependencies or release workflows for your team
  • We do not promise build times that have not been validated for your project
  • We do not present shared virtual resources as dedicated physical nodes
Operating principles

There is one set of product facts, even when the presentation language changes

RunnerVM’s multilingual pages, plan details, checkout configuration, and support responses all reference the same product facts. Changing languages must not change configurations, prices, locations, or available payment options.

A

Accurate configurations

Every available device lists its chip, memory, storage, and physical attributes. Runner M4 currently means M4, 16GB, and 256GB. We do not add unavailable models or describe extra storage as standard configuration.

B

Consistent pricing

Daily, weekly, monthly, and quarterly prices stay consistent across plan, checkout, and related information pages. All orders are settled in USD; add-ons are listed separately, with no vague starting price hiding the full term cost.

C

Verifiable locations

The catalog clearly lists five available regions. When users choose a region, we show only combinations supported by the current model; network investigations record the source node, destination node, time, and complete output.

D

Traceable issues

Technical issues enter a ticket based on the order, node, time, reproduction steps, and redacted logs. Status, additional information, and conclusions are updated in the same ticket to keep everything together.

Configuration catalog 1 plan
Location catalog 5 nodes
Billing terms Day / Week / Month / Quarter
Payment options USDT-TRC20 or card

Card payments mean Visa, Mastercard, or Amex processed by Stripe. Actual gateway availability is returned by the backend interface; all orders are settled in USD.

Node locations

Five nodes cover major access routes across Asia and the US East

Location choice is not just about map distance. Teams should test member locations, code and dependency sources, remote-operation paths, artifact upload destinations, and corporate network egress before selecting an order region.

SG

Singapore

A strong choice for Southeast Asian development teams and for regional collaboration across Asia. Before ordering, test latency and routing from your actual office network.

JP

Japan (Tokyo)

A good fit for teams in Japan or with network paths close to Tokyo. For workflows involving frequent remote desktop use, also monitor p50, p95, and peak-evening performance.

KR

South Korea (Seoul)

A regional option for development and build workloads targeting South Korea. For large dependencies or artifacts, test download sources and upload destinations together.

HK

Hong Kong

Suitable for teams needing cross-border access routes in Asia. Actual routing can vary by carrier, so a location name cannot replace project-specific network testing.

US-E

US East

A good fit when team members, code services, or delivery paths are primarily oriented toward the eastern United States. For cross-continent remote operations, prioritize automation and retain complete logs.

Test remote interaction before the build path

From your actual network, check ping, traceroute, DNS, and the target port separately, then run dependency retrieval and artifact upload close to a real project workflow. Public latency data is for comparison and does not replace your team’s own network tests.

View the network troubleshooting guide
Device and data responsibilities

Every step has a clear owner, from pre-delivery checks to order completion

A dedicated device still requires careful access control. RunnerVM handles node delivery, service-side credentials, and post-order device processing; users handle initial security settings, project permissions, build materials, and business-data backups.

  1. 01

    Verify the device before delivery

    Confirm the available model, memory, base storage, network connection, and device accessibility, then associate the order with the user-selected region. Delivery details are determined by the order and console response.

    RunnerVM responsible: configuration and node consistency
  2. 02

    Update security settings after the first connection

    After receiving connection credentials, verify the host fingerprint, change the initial password, restrict unnecessary access sources, and check that remote desktop and command-line connections follow team policy.

    User responsible: credential storage and permission assignment
  3. 03

    Control project data during the rental

    Organize certificates, provisioning profiles, source code, caches, logs, and build artifacts in project-specific directories. Use least privilege when sharing with teammates and keep separate backups of critical artifacts.

    Shared goal: limit privilege sprawl and data mixing
  4. 04

    Revoke access when the order ends

    The service revokes connection credentials associated with the order and begins device processing. Users should export artifacts they need to keep, remove project keys, and confirm that automated jobs no longer send data to the node.

    Completion criteria: access revoked, jobs stopped, data handled

Content users must back up themselves

Build artifacts outside the source repository, exported files, project logs, custom scripts, files that exist only in caches, and configuration records the team will need later.

Redact data before submitting support information

Keep timestamps, commands, error codes, and context in logs, but remove passwords, tokens, private keys, certificate passphrases, and anything else that could directly grant access.

Public status and improvement

Status records explain what happened; reviews explain what changes next

RunnerVM targets 99.9% service availability. Nodes operate normally 365 days a year; unexpected device, external-network, or user-configuration issues are recorded and handled according to their actual impact.

Service availability target 99.9%

The applicable service terms govern how incidents are determined, verified, and handled.

90 days ago 3 days per cell Most recent record

The status bar shows the record span for the last 90 days. Actual availability at checkout is returned in real time by the console.

Record

Make incident information locatable

Record start and end times, affected nodes, user-visible symptoms, confirmation methods, and recovery results instead of publishing status conclusions without defined scope.

Response

Restore first, then verify the scope

Restore device or connection capability first, then verify the impact using the order, node, time, and logs, and update the response status through the ticket.

Review

Every improvement must be actionable

Review summaries distinguish device, network, delivery, and process issues, and define checks, owners, and verification methods without unverifiable absolute promises.

Daily records Node connectivity and service status
Incident records Time, scope, symptoms, and recovery results
Review summary Cause categories, improvements, and verification paths
Do configurations and prices differ between language versions?

No. Page language changes only how information is presented—not available models, term prices, add-ons, location listings, or payment options. If you find inconsistent information, submit the specific page and screenshot through support@runnervm.com or a console ticket.

Will RunnerVM choose a node for our team?

Not directly. We publish five node locations—Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and US East—and provide network troubleshooting methods. Your team should test using its actual office network, dependency sources, and delivery targets before choosing.

How can we troubleshoot build or connection issues faster?

First record the order ID, node region, time, reproduction steps, and complete error output, then check the support guide. If the issue remains, sign in to the console and submit a ticket; remove credentials and sensitive materials from logs before submitting.

Your next build

Put repeatable builds on a dedicated cloud Mac

Review Runner M4 configuration, term, and five available locations, then start checkout. To discuss project requirements, contact the team through the support email or a console ticket.

Start renting a cloud Mac Contact the support team