Dedicated macOS CI for teams
From $20/day for a complete Apple Silicon M4 Mac mini dedicated to your builds. Choose 16GB or 24GB RAM, with no CPU sharing between customers.
Choose a billing term, then compare plans. Confirm the term and order total at checkout.
View prices by billing term
One runner, one entire machine
Both plans include a dedicated Apple Silicon M4 Mac mini—not a virtual machine. They differ in memory and onboard SSD capacity; the machine is never split between customers. Your team controls workload concurrency and queuing through runner configuration.
Prices shown are per day in USD; full-term prices are also listed on each plan.
A starting point for single-project CI
$20/day
A good fit for single-project builds, unit tests and small SwiftUI apps. Run your own repository first and check peak memory, cache size and build artifacts before deciding whether to add storage.
More headroom for multiple targets and graphics work
$39.5/day
Well suited to everyday remote Xcode work, multi-target projects and parallel UI tests. More RAM and SSD space give simulators, dependencies and build caches room to grow; tune concurrency based on your own project tests.
Both plans are available at all 5 locations. Check the console for real-time availability. Each price covers the full rental term; charges are not based on build minutes.
| Plan | Chip / RAM / SSD | Daily | Weekly | Monthly | Quarterly |
|---|---|---|---|---|---|
| Merge M4 S | Apple Silicon M4 16GB RAM / 256GB SSD | $20 | $54.1 | $100.1 | $272.3 |
| Merge M4 L | Apple Silicon M4 24GB RAM / 512GB SSD | $39.5 | $106.7 | $197.6 | $537.5 |
Choose based on your workload
Project count isn't the only factor. Simulators, dependency resolution, archiving and model loading can all use resources at the same time. An SSD add-on gives you more storage, not more RAM, and won't automatically speed up every task.
| Workload | Suggested plan | Why this plan | What to check after setup |
|---|---|---|---|
| Light builds | Merge M4 S 16GB RAM / 256GB SSD | Start with a dedicated build environment for single-project CI or a small SwiftUI app, without paying for resources you don't yet need. | Record resource usage for one clean build and one cached build, then check free space after archiving. |
| Everyday development | Merge M4 L 24GB RAM / 512GB SSD | Multi-target projects, parallel UI tests and remote Xcode often use memory at the same time. This plan leaves more headroom for your toolchain and simulators. | Run the test combinations you actually need, watch memory pressure, then set runner concurrency accordingly. |
| Large-model inference | Merge M4 L With the +2TB SSD add-on | Run local inference with MLX on Apple Silicon. Larger model files need more disk space, but loading a model still depends on available memory. | Check model precision, context length and memory requirements first, then plan where to store model weights and datasets. |
Test your own repository by the day: pin the Xcode version, dependency lockfile and test suite, then compare build logs. Build times from different projects aren't a reliable way to compare hardware.
Expand as needed
These add-ons are priced separately from the base plan and listed by billing term. Check whether you need more local storage or machine-to-machine connectivity, then review the combination and total on the order page.
More room for dependency caches and build artifacts
A good fit when the project itself is small but DerivedData, build caches and archived artifacts keep growing. Set up cleanup and backups; extra storage is not a backup.
Adds storage capacity without changing the base plan's RAM.
More room for model files and large asset sets
Store MLX model weights, multiple simulator runtimes or large assets. Include downloads, extracted copies and generated artifacts in your estimate—not just repository size.
Model workloads are still limited by RAM and task configuration.
Multi-machine add-on, priced per machine
For multi-machine workflows that genuinely need machine-to-machine connectivity. It doesn't combine RAM across Macs or make Xcode build across machines automatically; first check that your application can use the connection.
Check the order page for the exact connection setup and available combinations.
Select storage and linking add-ons when you place your order. To change an existing instance, submit a support ticket describing your use case, data migration needs and preferred changeover time.
5 locations, same plan selection
VNC responsiveness depends more on round-trip latency; automated builds also depend on the network path taken by your code, dependencies and artifacts. The ranges below are references for each location's service area—not measurements from your location or tests in every city.
| Location | Service area | Reference round-trip latency | Good for |
|---|---|---|---|
| Singapore | Southeast Asia | 20–50 ms | Remote desktop and builds for Southeast Asian teams. For file transfers, consider where your repository and artifacts are stored. |
| Japan (Tokyo) | East Asia | 30–60 ms | Interactive Xcode work and automated builds for East Asian teams. Reuse local caches when transferring assets frequently. |
| South Korea (Seoul) | Northeast Asia | 30–50 ms | Remote desktop and testing for Northeast Asian teams. Check throughput and stability separately when sending artifacts back. |
| Hong Kong | Southern China and Southeast Asia | 20–40 ms | Graphics development and SSH builds in the service area. Syncing small files can reduce repeated transfers. |
| US East | Eastern North America and Western Europe | 25–35 ms | Builds and remote collaboration for teams in the service area. Choose based on the location of your dependency sources, code and artifacts. |
These are reference ranges; your actual results depend on your network. Latency isn't download speed. Test initial dependency downloads, archive uploads and VNC responsiveness separately. Both plans are available in all listed locations; check the console for real-time availability.
Give nightly builds a reliable home
99.9%
Based on a 30-day month, that allows for about 43 minutes of downtime.
All locations operate year-round, 365 days a year. The uptime commitment doesn't guarantee every pipeline will succeed: investigate build errors, dependency failures and user actions separately in your build logs.
If downtime exceeds the allowance, service time is credited based on the affected duration. Force majeure and issues caused by user actions are outside the commitment. Keep instance status and relevant logs to help verify the cause and duration.
To request a review, sign in to the console and submit a support ticket with your instance ID, the affected start and end times (including time zone), and records of connection or task failures. Never include passwords, private keys or signing certificates in a ticket.
Four billing terms, all in USD
Use daily billing to test a project, weekly for a short build phase, or monthly or quarterly for a runner you plan to keep running. All prices are in USD. Before checkout, review the base plan, add-ons and billing term together.
Transfer using the payment details shown for your order
Verify the network, recipient details and order total, and keep the transaction hash. Check your order status in the console to confirm payment. If you've transferred funds but payment isn't confirmed, submit a ticket with the transaction record before trying again.
Card payments processed by Stripe
Complete any verification required by your card issuer during checkout. If payment fails, check the payment message and confirm your card's permissions and verification status. Never send your full card number or security code by email or in a support ticket.
Only these two payment methods are supported. Available payment gateways depend on the backend response. Payment confirmation and instance provisioning are separate steps; check both your order and instance status in the console.
Plan ahead for future changes
Changes to an existing instance can affect its environment and data. Check which operations are available before making changes. Don't delete a runner that's handling a release just to change its configuration.
To move from Merge M4 S to Merge M4 L, first check the available options in the console. If there's no suitable option, submit a support ticket with your instance ID, target plan and preferred changeover time. These are different physical configurations—not a live RAM upgrade.
Before confirming a plan, back up files outside your repository, runner settings, certificates and build scripts. Check the console or support ticket for the change method, cost and whether a new instance is required.
Sign in to the console to check your instance's expiry date, associated invoice and available renewal options, then pay the amount shown. Don't assume renewal is complete just because you were redirected from the payment page; return to the console and confirm the invoice and instance expiry date.
Renew locations you plan to keep before they expire. For instances you plan to release, first retrieve your project, archives and required configuration. Once an instance expires and is released, its disk is erased; the instance disk is not a substitute for your team's own backups.
An SSD add-on is a separately billed storage expansion. Check the console or submit a support ticket to confirm whether it can be removed from an existing order. Deleting files won't automatically stop add-on billing.
Move models, caches and artifacts off the add-on drive first. Confirm your build scripts, mount paths and runner working directory no longer depend on it, then check when the change takes effect and how it affects future invoices.
You can provision multiple instances under one account, each with its own dedicated physical machine and billing. Set runner tags for each location or workload, register each machine with your team's CI platform, then configure job routing and concurrency limits.
Machines don't automatically share working directories, caches or signing materials. Give each instance a separate runner identity, and manage credentials and build artifacts centrally. Thunderbolt 5 linking doesn't automatically create a distributed build cluster.
Start with one dedicated M4 and test your toolchain and build workflow on a real project. Choose your plan, location, rental term and add-ons on the order page.