Task duration
Schedule one-off validation by the day, version sprints by the week, and continuous integration or always-on experiments by the month or quarter to reduce repeated environment setup.
Input: expected runtime
Workload matching
Match M4 nodes to real workflows
Runner provides Cloud Macs for project-based rental periods. Each order includes one dedicated Apple Silicon physical machine—not a virtual machine—ideal for teams that need a fixed toolchain, a full macOS GUI, or continuously running tasks.
Start by filtering for runtime, memory usage, GUI requirements, and concurrency—there’s no need to guess the model first.
BUILD ROUTE
Workflow completion record
Node available
01
Submit
Code, assets, or models
02
Run
Run tasks in a fixed environment
03
Review
Return test results and deliverables
- Node type
- Dedicated physical server
- Access methods
- SSH and GUI
- Rental terms
- Day / week / month / quarter
- Plan lineup
- Two M4 plans
Delivery principle
One node per order
Define the task first
Four questions to narrow your plan
The application type alone does not determine the right configuration. First confirm how long the task runs, where memory peaks, whether it depends on a GUI, and how many build or experiment processes run at once.
Memory needs
Standard Xcode projects and lightweight automation can start with 16GB. If you run simulators, multiple builds, or larger models together, evaluate 24GB first.
Input: peak memory and concurrency
Graphical interface
Use SSH primarily for scripts and build commands. Add a remote GUI when you need to operate Xcode, timelines, preview windows, or system settings.
Input: steps that require visual interaction
Task concurrency
Track whether tests, packaging, model inference, and exports overlap. Concurrent tasks share memory, disk cache, and network bandwidth, so choose by peak usage rather than averages.
Input: number of simultaneous jobs
Real task paths
Four workflow types, side by side
These scenarios are not mutually exclusive. The same node can support development and debugging before joining an automated pipeline; the key is to keep the environment, cache, and delivery boundaries clear at every stage.
Independent developer
Remote development, signing, and submission
Open Xcode through the GUI, pull your code, and select the toolchain required by the project. Run tests, create a signed build, then return the archive and logs to your own storage.
- Ideal for short projects, version fixes, and pre-submission validation
- Pin Xcode and dependency versions before importing signing materials
- Retrieve archives, logs, and required caches before finishing
CI team
Dedicated self-hosted runner
Register the physical node to a specific project or organization, restrict its trigger scope, maintain dependency caches, and return test reports, archives, and symbol files to pipeline artifact storage.
- Ideal for continuous testing, scheduled builds, and releases
- Isolate keys, tokens, and signing materials by project
- Clean working directories regularly and track cache usage
AI experiments
Validate MLX and local models
Check model, framework, and dependency compatibility on Apple Silicon. Estimate memory from model weights, context length, and concurrent requests, and keep experiment data separate from results.
- Validate the environment and inference path with the smallest sample first
- Monitor unified memory and disk-cache usage continuously
- Remove weight copies and temporary data after the experiment
Media team
Sync assets, preview, and export
Transfer proxy files or essential assets first, then inspect the timeline and preview through the remote GUI. Plan caches, source files, and export folders separately, and retrieve finished media and project files promptly.
- Ideal for remote editing validation, batch transcoding, and exports
- Confirm asset size and network conditions before uploading
- Do not estimate rendering or transfer results from a fixed duration
iOS / macOS development
From code checkout to signed builds, keep the toolchain reproducible
Development work often stalls when something runs locally but cannot be reproduced remotely. Record versions, dependencies, signing materials, and artifact paths clearly so the node can switch reliably between a debug machine and a build machine.
When Runner M4 is a good fit
Single-project development, standard unit tests, one main build task at a time, with 16GB of memory and a 256GB SSD able to hold the code, dependencies, and required caches.
Development delivery sequence
DEV-TO-ARCHIVE
01
Pull the code
Check branches, submodules, dependency sources, and repository access scope. Do not store long-lived credentials in the project directory.
02
Select Xcode
Pin the Xcode and command-line tool versions required by the project. Run an environment check once before installing dependencies.
03
Run tests
Start with a small test scope to confirm the simulator, target platform, and permissions, then expand to the full test suite.
04
Create the build
Inject certificates and signing files from a controlled location, then output the archive, test report, and required diagnostic logs.
05
Retrieve artifacts
Return the archive and logs to team storage. Confirm file integrity before clearing temporary directories and sensitive materials.
CI/CD execution
Let the runner accept only the jobs it should run
A dedicated physical server provides clear resource boundaries, but the pipeline still needs limits on trigger sources, project scope, and credential permissions. Managing runner registration, cache policies, job cleanup, and artifact delivery separately reduces the risk of cross-task contamination.
Signals for parallel-workload sizing
If builds, tests, archives, or multiple projects run simultaneously, record peak memory and cache size. When you need more memory headroom and a larger local SSD, evaluate Runner M4 Plus first.
Automation runbook
RUNNER-SCOPE
Limit registration scope
Bind the node to a clearly defined project or organization and control which workflows can invoke it.
Isolate runtime credentials
Have your team’s secrets-management process inject tokens, certificates, and environment variables, then revoke temporary permissions when the job ends.
Layer your caches
Use separate directories for dependency caches, build intermediates, and final artifacts, with cleanup rules that can be reviewed.
Return verifiable artifacts
Send test reports, archives, symbol files, and checksums to pipeline storage. Do not treat the node as the only copy.
Nodes run normally 365 days a year with no scheduled downtime.
AI experiments
Validate compatibility before scaling models and data
On Apple Silicon, start with framework versions, model formats, and operator support instead of copying parameters from other hardware environments. MLX and local-model tests also share unified memory, so model weights, context, concurrent requests, and other processes must be budgeted together.
When to consider 24GB
When model weights, long contexts, data preprocessing, and multiple experiment processes must stay resident together—or a 16GB environment frequently hits memory pressure—Runner M4 Plus provides more working space.
Pre-experiment checklist
MLX / LOCAL MODEL
- Environment compatibility
- Confirm that macOS, Python, the framework, and the model format work together.
- Memory budget
- Record peak usage for weights, context, cache, input data, and concurrent processes.
- Data preparation
- Sync only the data required for the experiment, separating raw data, processed results, and temporary copies.
- Minimum validation
- Run a small sample and a single request first, then gradually increase data volume and concurrency.
- Collect results
- Save parameters, logs, and required outputs so the team can review the experiment.
- Cleanup
- Remove model copies, temporary data, tokens, and environments no longer in use.
Media workflow
Track transfers, caches, previews, and exports separately
Waiting time in remote media work comes from more than exporting. Asset uploads, proxy generation, remote display quality, and result downloads all affect the experience, so fixed render times should not be promised. A more reliable approach is to verify network, storage, and task status step by step.
Calculate reclaimable storage first
In addition to source assets, reserve space for proxy files, render caches, automatic project saves, and final exports. If 256GB cannot hold the combination, choose the m4-24-512 configuration or evaluate an SSD add-on on the plan page.
Asset handoff sheet
MEDIA-HANDOFF
Sync assets
Upload the assets or proxy files required by the project first, retain local originals, and verify transfer integrity.
Remote preview
Adjust the GUI session resolution to match network conditions; smooth preview playback does not equal final export quality.
Manage caches
Store caches and source assets in separate directories, and confirm free disk space before important exports.
Retrieve exports
After exporting, verify file size and playability, return the files to team storage, and remove temporary copies.
Plan matching
Choose between two M4 plans by peak demand
Both plans include a dedicated physical server, SSH, and the macOS GUI. The difference is memory, SSD capacity, and price—not an unclear shared-resource multiplier.
Standard development and lightweight automation
$20.6/ day
Runner M4
ChipM4
Memory16GB
SSD256GB
Suitable for single-project Xcode development, one main build task at a time, a lightweight self-hosted runner, short-term compatibility testing, and workflows without large local media assets.
- First confirm that dependencies and caches fit on the 256GB SSD
- Best for tasks that primarily use SSH with GUI access when needed
- Monitor peak memory and disk usage before increasing concurrency
Higher memory and storage needs
$40.8/ day
Runner M4 Plus
ChipM4
Memory24GB
SSD512GB
Suitable for parallel simulator and build workloads, multiple automation jobs, larger MLX experiments, more dependency caching, and workflows that temporarily store proxy media and exports on the node.
- Keep more headroom for concurrent processes and unified memory
- The 512GB SSD holds more caches, models, or media files
- You still need to retrieve artifacts and clear data before the rental ends
Still unsure about memory or storage before ordering?
Get sizing advice
Gather your project size, Xcode version, number of concurrent jobs, cache size, and expected rental term, then send them to the team through the contact page. Do not submit passwords, private keys, or complete payment credentials.
Configure from your workflow
Choose the model, rental term, and node, then place your order
Runner supports daily, weekly, monthly, and quarterly rentals. All charges are settled in USD; accepted payment methods are USDT-TRC20 and Visa / Mastercard / Amex (via Stripe). The gateway actually available is determined by the console.