Deployment path

From plan selection to a test build: set up your first cloud Mac

This guide is for developers and build teams renting XcodeVM for the first time. Confirm your use case, configuration, node, billing, remote connection, toolchain, and security baseline in order, then complete acceptance with a reproducible test build.

Before you begin

Define the workload before choosing the machine

Spend ten minutes documenting your constraints before selecting a plan. This is usually faster than moving repositories, caches, and build artifacts repeatedly after provisioning. Keep this information as an internal deployment baseline; it does not need to be shared with unrelated parties.

Define the development use case

Distinguish interactive development, scheduled builds, continuous integration, iOS or macOS release builds, React Native, Unity iOS workflows, and MLX experiments. Record the number of simultaneous projects, parallel jobs, and typical build duration.

  • Lightweight scripts and single-project builds prioritize baseline configuration and flexible billing terms.
  • Multiple repositories, simulator jobs, or high-concurrency builds require more available memory.
  • For model experiments, first verify model size, inference method, and peak memory usage.

Estimate memory and storage

Do not look only at repository size. Include dependencies, build caches, archives, logs, and temporary directories. Continuous integration jobs should also reserve space for parallel workspaces and failed-build samples.

  • Measure the project's actual peak memory usage, not idle consumption.
  • List the SDKs, toolchains, and dependency caches that must remain on the machine.
  • Decide when to move build artifacts to avoid long-term accumulation in the workspace.

Check the repository and connection environment

Confirm the target repository's access method, team network policy, remote client, and local keyboard layout. If your corporate network restricts outbound connections, have a network administrator verify the required routes in advance.

  • Prepare least-privilege repository credentials and required signing materials.
  • Identify the carrier used by the office network, home network, or build gateway.
  • Record the expected rental term and reserve time for environment setup and data migration.
Starting conditions: You should be able to answer five questions: “What will run, what is the peak usage, where will the data live, where will you connect from, and how long will you rent it?” If you are still unsure, start by reviewingDeployment model comparison, then decide whether a fixed-location dedicated physical machine is right for you.

Step 1 · Choose a plan

Choose between two M4 configurations based on concurrency and memory needs

XcodeVM offers two Mac mini M4 configurations. Each is a cloud Mac on a dedicated physical machine, not a virtual machine. Choose memory based on the real workload, then verify local storage against workspace and cache size.

Plan Hardware configuration Best for Term pricing Recommendation
XVM M4 Core
m4-16-256
M4 / 16GB / 256GB Light builds, script automation, everyday single-project development, and low-concurrency continuous integration. $19.1/day
$51.7/week
$95.7/month
$260.3/quarter
Run a complete build with a representative repository first. If memory stays close to the task limit or you need more parallel jobs, consider Plus.
XVM M4 Plus
m4-24-512
M4 / 24GB / 512GB Multi-project development, higher-concurrency builds, larger dependency caches, and MLX experiments requiring more memory headroom. $39.5/day
$106.6/week
$197.4/month
$536.9/quarter
Do not judge model inference by name alone. Verify model size, quantization, runtime overhead, and peak memory before deciding whether the configuration meets your needs.

If you need more workspace, review the +1TB SSD, +2TB SSD, and Thunderbolt 5 parallel options during checkout. Add-ons are billed separately; the final configuration and availability are determined by the console in real time.

Step 2 · Choose a node

Test carrier routes before relying on map distance

The four available nodes are Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Geographic distance is only an initial filter; the real remote experience also depends on your local carrier, international egress, office-network congestion, and routing changes.

SG

Singapore

Suitable for teams connecting through Southeast Asian routes. Test from both your office and backup networks instead of relying on a single egress.

JP

Japan (Tokyo)

A candidate for Northeast Asian development routes. Record round-trip latency and jitter during both working hours and off-peak periods.

KR

South Korea (Seoul)

Suitable for teams evaluating connection quality toward South Korea. Cross-border routes can change, so collect multiple samples rather than relying on one result.

HK

Hong Kong

Useful for evaluating cross-border remote development and build routes in Asia. Corporate-network users should also verify proxy, firewall, and egress policies.

Node testing method

Collect at least three comparable data sets

Run multiple tests for each candidate node on the same network and at similar times. Record P50, P95, packet loss, carrier, and connection location. If your team is distributed, test from each region instead of treating one member's result as representative.

ping -c 30 "$NODE_HOST"
traceroute "$NODE_HOST"
date -u
networkQuality

Step 3 · Checkout

Verify the term, configuration, node, and USD amount

Choose a daily, weekly, monthly, or quarterly term based on the actual task duration. Do not compare only the headline price; also account for setup, stable operation, troubleshooting, and migration before the term ends.

Review each item before placing the order

  • The plan name, M4 chip, memory, and local storage match your requirements.
  • The node is the target location among Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong.
  • The selected daily, weekly, monthly, or quarterly term covers setup, execution, and data migration.
  • Add extra storage and Thunderbolt 5 parallel options only when needed.
  • The order total is shown in USD and matches the checkout configuration.
  • Actual node and configuration availability is determined by the console in real time.

Payment and billing

Only the following two payment categories are supported. All orders are billed in USD, and available gateways are determined by the backend interface.

Digital assets
USDT-TRC20
Cards
Visa / Mastercard / Amex (via Stripe)
Open checkout configuration

Step 4 · First connection

Verify session stability before migrating your work

After receiving your provisioning details, do not immediately import every repository and key. First save your credentials and test the remote session, input devices, time zone, and reconnection to confirm a reliable access path.

  1. 01

    Verify the provisioning details

    Confirm that the order ID, node, model, memory, storage, and connection instructions match the order. Store the order ID in a team-controlled operations record for future support requests.

  2. 02

    Save and update the initial credentials

    Store login details in a controlled credential manager, never in public documentation, chat history, or repository commits. Update the initial credentials after first login and confirm that the new credentials reconnect successfully.

  3. 03

    Establish graphical and command-line sessions

    Verify that both the macOS graphical interface and command line work. Check the remote client's resolution, scaling, color quality, and clipboard policy to avoid mistaking local display settings for node performance.

  4. 04

    Calibrate the keyboard and time zone

    Test Chinese and English input, function keys, modifier keys, and common shortcuts. Set the system time zone to the team's agreed value and ensure build logs, signing records, and monitoring use the same time reference.

  5. 05

    Disconnect and reconnect deliberately

    Save your work, deliberately disconnect the session, and reconnect. Confirm that the window state, terminal processes, and background builds behave as expected. If reconnection fails, record the local time, node, carrier, and error text.

Step 5 · Initialize development

Build the toolchain and cache directories with reproducible scripts

Put the setup process in a script or internal runbook. The goal is not merely a successful one-time installation, but for the team to understand where every tool comes from, how versions are pinned, where caches live, and which logs to inspect when something fails.

Toolchain

Install only components required by the current project

Check version requirements for macOS, Xcode, command-line tools, runtimes, and package-manager dependencies. Install the minimum set first, then add debugging and analysis tools after the test build passes.

Repository access

Pull code with least-privilege credentials

Configure restricted repository access for the machine and verify that read-only or read-write scope matches the task. Key files must not enter the repository, build artifacts, or publicly readable log directories.

Signing materials

Separate import, use, and backup paths

Import only the signing materials required for the current build, restrict file permissions, and record the owner and rotation process. When outputting logs, hide sensitive content beyond certificate fingerprints.

Cache strategy

Separate dependencies, derived data, and archives

Use separate directories for dependency caches, derived data, temporary builds, and final archives. Define capacity thresholds and cleanup order so cleanup scripts do not remove artifacts that still need to be retained.

bootstrap / validation
mkdir -p "$HOME/workspace"
mkdir -p "$HOME/build-cache"
mkdir -p "$HOME/build-artifacts"

git clone "$REPOSITORY_URL" "$HOME/workspace/project"
cd "$HOME/workspace/project"

xcodebuild -version
sw_vers
df -h "$HOME"

xcodebuild \
  -workspace "$WORKSPACE_NAME" \
  -scheme "$SCHEME_NAME" \
  -configuration Debug \
  -derivedDataPath "$HOME/build-cache/DerivedData" \
  build | tee "$HOME/build-artifacts/test-build.log"
Environment details recorded LOG SAVED
Test build acceptance criteria: The repository can be cloned, dependencies resolve, the target scheme is recognized, the build completes without unexplained errors, artifacts enter the designated directory, and logs contain no complete credentials or unredacted business data. If the build fails, preserve a copy of the original log before retrying.

Step 6 · Security hardening

Bring credentials, permissions, keys, and backups into the daily workflow

A dedicated physical machine does not replace application-level security controls. Your team must still manage access permissions, repository credentials, signing materials, build logs, and business data, and complete migration before the rental term ends.

Credentials and least privilege

Update initial credentials and create restricted access for automated tasks. Avoid having multiple people share the same high-privilege login for long periods, and regularly revoke repository and build permissions that are no longer needed.

Keys and sensitive materials

Store keys, tokens, and signing materials in controlled locations, never as script constants, in repository history, or in ordinary logs. Before submitting a support request, inspect command output and remove tokens, private keys, and complete business data.

Application-level backups and migration

Back up data beyond the code, including configuration, build artifacts, experiment records, and necessary logs. Run recovery tests regularly and migrate required data to a team-controlled location before the rental term ends.

Seven rules for your team baseline

  • Update initial credentials immediately after first connection and verify that you can log in again.
  • Use separate permission scopes for repository access, automated builds, and human operations.
  • Never write private keys, complete payment credentials, or account passwords to build logs.
  • Enable collaboration through controlled permissions instead of sharing high-privilege credentials long term.
  • Separate build caches from final artifacts and define individual cleanup and retention rules.
  • Backups must include recovery validation; “the file was copied” is not proof of recoverability.
  • Complete data migration, credential revocation, and cleanup of sensitive local files before the rental term ends.

Acceptance checklist

Connect it to your production workflow only after these conditions are met

Acceptance records should allow another engineer to review the setup. Do not write only “works”; record the node, configuration, test method, build result, and route for handling exceptions.

  • Node: The selected location matches the order, and multiple route tests have been completed from the actual office carrier.
  • Hardware: The chip is M4, and memory and storage match the ordered configuration of XVM M4 Core or XVM M4 Plus.
  • Network: Both graphical and command-line connections can be established, and the session reconnects as expected after a deliberate disconnect.
  • Input environment: Display resolution, scaling, keyboard layout, modifier keys, and time zone match the team's conventions.
  • Repository: The repository was pulled with least-privilege credentials, and sensitive materials did not enter the repository or ordinary logs.
  • Build: A representative target completed one clean test build, with artifacts and logs placed in the designated directories.
  • Storage: Workspace, cache, temporary-file, and archive boundaries are clear, with capacity and cleanup rules documented.
  • Security: Initial credentials have been updated, access has been narrowed, and application-level backup and recovery have been validated.
  • Monitoring: The team knows how to check resource status, record incident times, and collect redacted logs.

Start deployment

Document your requirements, then provision your first cloud Mac

Choose from two M4 configurations and four Asian nodes, with daily, weekly, monthly, or quarterly billing. After provisioning, follow this page to complete connection, test builds, the security baseline, and acceptance records.