Four teams. Four workflows.

1. Commit your code

   Develop on Windows and push a tested commit to your repository. Commit the dependency lockfile with your code to ensure the remote build uses the same dependencies.

2. Create the archive

   The Tokyo server pulls your code, installs the project dependencies, and runs flutter build ipa. You configure the signing certificate, provisioning profile, and access permissions.

3. Upload for distribution

   Check the version and build numbers, then use fastlane pilot to upload to TestFlight. Save the IPA, logs, and corresponding commit ID in your own artifact storage.

You’ll still need valid developer credentials, signing assets, and an App Store Connect API key for TestFlight distribution. A remote server does not replace these requirements.

1. Register a runner

   Install a GitHub Actions self-hosted runner on the Singapore server. Use labels to route macOS jobs to it, and restrict which repositories and branches can trigger jobs.

2. Set job priorities

   main builds and runs basic checks on merge; keep release branch jobs separate; nightly runs longer simulator UI tests.

3. Isolate working directories

   Use separate working directories and DerivedData for each branch or job. Track peak memory, disk growth, and queue times before deciding whether to increase concurrency or add another server.

Choose a region based on repository pulls, dependency downloads, and artifact uploads—not just where your team is located. If you work across regions, test with your own project first.

1. Check compatibility

   Make sure your inference framework supports Apple Silicon and the operators you need. Estimate memory use from model weights, context length, and runtime overhead—not just the model file size.

2. Keep evaluation inputs consistent

   Download models you’re authorized to use and record their versions, quantization settings, and prompt sets. Use the same inputs for every run, and measure initial loading separately from subsequent inference.

3. Save experiment results

   Export throughput, peak memory, and evaluation results to your own storage. Once you’ve confirmed the model runs, decide whether to keep the environment on a monthly plan.

This is an example of a compute workflow, not a promise of model speed or quality. During your trial, measure memory, initial load time, and sustained inference—not just a single run.

1. Transfer and test a sample

   Upload media you’re authorized to process. Start with a short clip to verify codecs, color settings, and export parameters. Include upload time in your delivery estimate for the full batch.

2. Queue your exports

   Use scripts or your application’s batch processing tools to organize jobs. Increase parallelism gradually and monitor memory and disk I/O to prevent exports from slowing each other down.

3. Retrieve files and clean up

   Check audio sync, duration, and file integrity, then retrieve the finished files and job logs. After confirming your backups, delete intermediate files to free space for the next batch.

First estimate peak usage for source media, caches, and exports against the included 2TB SSD. Add the optional +2TB SSD only if you actually need more space.