HARDWARE GALLERY

The Mac assigned to you—not a slice of shared capacity

Every order maps to a dedicated physical machine. Its processor, memory, and local storage are not shared with other tenants. The portal shows the device through its node ID and connection status instead of placing multiple users inside one virtual instance.

All nodes run normally 365 days a year with continuous availability. Immediate delivery depends on the real-time status of the selected model and region; the portal confirmation is authoritative.

PORTAL CONFIGURATION

The portal breaks your purchase decision into four fields you can verify

Choose the fixed hardware first, then select the region, term, and add-ons. Review each item before submitting instead of guessing memory, storage, or delivery location from an unclear package name.

MW Node Configuration
ORDER DRAFT
STEP 1 / 4

Choose a Physical Node

Configuration Example
Forge M4SELECTED

M4 · 16GB · 256GB SSD

Studio M4

M4 · 24GB · 512GB SSD

Atlas M4 Pro

M4 Pro · 64GB · 2TB SSD

Region Japan (Tokyo) Other options: Singapore, Seoul, Hong Kong, U.S. East
Term Monthly Daily, weekly, or quarterly options are also available
Add-on +1TB SSD Matches the selected service term
Payment U.S. dollars (USD) Two specified payment methods supported

Configuration is not inferred from abbreviations

Each model card lists the chip, memory, and SSD capacity. Extra storage and Thunderbolt 5 parallel access enter the order only when explicitly selected.

Access is managed in one place after delivery

Once the node is ready, its status, login details, browser-based remote desktop, and SSH information are available in the same order context, so you do not have to assemble parameters across pages.

Public views are anonymized by default

This page hides order IDs, full node IDs, network addresses, usernames, and authentication data. The live console provides corresponding data only to authorized signed-in users.

DEVELOPER DESKTOP

View your project, commands, and resource changes in one desktop

The development desktop uses a familiar four-zone layout: project navigation, editor, build logs, and resource monitoring. You arrange the actual windows yourself, with the full macOS GUI and command line available.

Development Workspace
CPU 38%MEM 9.6 / 16GB
BuildPipeline.swift Package.swift
  1. struct BuildPipeline {
  2.   let scheme = "SampleApp"
  3.   let configuration = "Release"
  4.   
  5.   func archive() async throws {
  6.     try await prepareDependencies()
  7.     try await runTests()
  8.     try await exportArtifact()
  9.   }
  10. }
BUILD LOGEXIT 0
$ xcodebuild -scheme SampleApp -configuration Release archive
Resolve Package Graph
CompileSwiftSources normal arm64
Run unit tests: 128 passed
Archive path: ./Artifacts/SampleApp.xcarchive
BUILD SUCCEEDED
01

Your development environment stays in place

Dependency directories, tool versions, build caches, and scripts can remain on the same physical node. With weekly, monthly, or quarterly use, you do not need to rebuild the entire environment at the start of every session.

02

GUI work and automation run side by side

Use the browser-based remote desktop for interactive checks; run batch builds, log collection, and file operations over SSH. Both entry points target the same node, not two isolated environments.

03

Choose resources based on task history

Track build duration, peak memory, remaining disk space, and failure logs together. If memory stays near its limit, evaluate Studio M4 or Atlas M4 Pro from Forge M4 instead of choosing by task name alone.

CI/CD EXECUTION PATH

A build moves through four clear stages from commit to artifact

The dedicated node performs the actual work. Your team still configures code hosting, triggers, and artifact storage through its existing toolchain; MacWorker provides a remotely controllable physical macOS execution environment.

  1. 01

    Code Commit

    The developer pushes the designated branch or tag. Each commit should include reproducible dependency lists, build settings, and version information so the node does not depend on undocumented manual context.

    Input
    commit / tag
    Check
    Branch and configuration
  2. 02

    Job Trigger

    The pipeline creates a job from a branch, schedule, or manual action. Before scheduling, it checks node availability, the working directory, and concurrency policy, then sends commands to the designated execution node.

    Input
    job payload
    Check
    Queue and status
  3. 03

    Physical Node Execution

    The dedicated Mac pulls code, restores caches, resolves dependencies, compiles, and runs tests. Your team can pin tool versions and use logs to identify the exact command, exit code, and duration.

    Input
    source + cache
    Output
    log + result
  4. 04

    Artifact Output

    Archive files, test reports, and logs are written to the agreed directory, then uploaded by your team’s scripts to its own artifact system. Before release, verify the file digest, build number, and test results.

    Input
    build result
    Check
    hash + report
RUN #1842 At least six types of information remain for a traceable run
  • Commit identifier
  • Node identifier
  • Start and end times
  • Tool versions
  • Exit code
  • Artifact digest

AI INFERENCE WORKSPACE

AI experiments are about reproducibility—not piling on undefined capabilities

Suitable for model inference and validation tasks that run on the selected Apple Silicon configuration. This page does not promise specific model speeds, training capabilities, or untested framework compatibility; choose based on model format, peak memory, and real samples.

FILES experiment-014
  • models
  • model-q4.bin
  • configs
  • inference.yaml
  • scripts
  • run_inference.py
  • results
  • run-014.json
TERMINAL arm64 · zsh
$ python run_inference.py \
  --config configs/inference.yaml \
  --model models/model-q4.bin \
  --output results/run-014.json

runtime: arm64
samples: 120
warmup: 5
result: archived
status: completed
OBSERVATION RUN 014
Peak memory41.8GB
Sample count120
Run statusCOMPLETED
ARCHIVE 4 ITEMS
Configuration
inference.yaml
Dependencies
environment.lock
Result
run-014.json
Digest
sha256••••8c1a

Pin model and dependency versions first

Place the model file, configuration, run script, and dependency lockfile in clearly defined directories. The experiment result should answer which version and parameters were used, and on which node it ran.

Record peak values, not averages

Choose memory based on the peak during model loading and inference. The values shown here explain the observation structure only; they are not fixed performance figures for any model on every node.

Then archive the inputs and result digest

At minimum, the result directory should retain the configuration, dependency versions, run log, output file, and digest. For cross-node comparisons, keep the samples, parameters, and measurement method consistent.

Scope: MacWorker provides three fixed configurations—Forge M4, Studio M4, and Atlas M4 Pro. Whether a model runs depends on its format, framework compatibility, memory requirements, and your own environment configuration; this page does not imply extra acceleration hardware or unlimited resources.

VISUAL DISCLOSURE

Every public interface applies data minimization first

Content Hidden

Structural Information Retained

When reading these screens

Examples explain the information architecture and workflow; they do not constitute a fixed UI promise. Portal fields, button placement, and visual details may change as the product evolves, but the model, region, term, and add-ons in a confirmed order remain governed by the portal record.

Monitoring curves, run numbers, node identifiers, and experiment results are anonymized demonstration data and should not be used as performance benchmarks.