Follow the task path

Prepare, connect, run, then troubleshoot

This is more than a collection of isolated commands. First verify the order and node in the console, then establish the connection, reproduce the toolchain, and validate the task with logs you can retain. Applies to the NowMini M4 with 16GB RAM and a 256GB SSD on a dedicated physical node.

Rent a Cloud Mac now View connection steps

4 task types: Prepare, connect, run, troubleshoot
4 nodes: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong
1 configuration: NowMini M4 dedicated physical node

A traceable task path

A handoff-ready run sheet

Every step records its inputs, actions, and validation results. When something goes wrong, you do not have to start guessing from scratch.

01
Prepare the environment Order, region, credentials, access source
02
Connect to the node SSH, graphical session, host fingerprint
03
Run the task Xcode, runner, MLX, artifact archiving
04
Troubleshoot Timeline, reproduction steps, redacted logs

Find the issue faster

Start by describing your task

Enter terms such as “Xcode,” “SSH,” “runner,” or “disk” to keep the relevant steps in view. You can also select a task entry point below.

First-time setup

Complete six checks before connecting

Do not combine order confirmation, network access, and system initialization into one connection attempt. Record each result in order so authentication failures are easier to isolate.

Setup checklist

From console details to the first session

Use the order and node details returned in real time by the console. Do not copy the host address from an old ticket or team chat.

Confirm the order ID

Record the order ID, rental term, and NowMini M4 configuration to confirm that you are working on the intended order.

Verify the node region

Confirm Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong, and use the same region name across the team.

Read the system credentials

Verify the username, host address, and key requirements. Store credentials only in a controlled password manager, never in a code repository.

Confirm the access source

Record the office network, fixed egress, or runner source address. Avoid first-time initialization on an unknown public network.

Establish the first connection

Verify network reachability first, then verify the host fingerprint and key permissions. Do not change several variables before trying again.

Complete account initialization

Create the least-privileged environment required for the task, set the working and log directories, and save a validation record containing no secrets.

Hardware validation

Verify the M4, 16GB RAM, and base 256GB SSD. If the order includes a storage add-on, check available capacity and mount location separately.

Session validation

Record separately whether SSH and the graphical session can be established, how long the first connection takes, and whether keyboard input and clipboard access meet task requirements.

Open connection instructions

Development environment

Reproduce the toolchain in dependency order

Pin tool versions first, then add credentials, caches, and signing materials. Reversing the order often makes a version issue look like a permissions issue.

Step 1

Pin the Xcode toolchain

Confirm the selected developer directory, then record the Xcode and SDK versions. Team pipelines should treat versions as build inputs rather than rely on interactive selection.

Check the command-line tools path
Record compiler and SDK versions
Complete a baseline build with a minimal project

Step 2

Configure Git credentials

Configure a dedicated key for the node or automation account with access only to the required repositories. After the first pull, record the remote URL, branch, and commit baseline.

Verify key-file permissions
Check repository read/write boundaries
Keep secrets out of script arguments

Step 3

Separate dependencies and caches

Keep rebuildable dependencies, build caches, and final artifacts separate. Cache keys should include at least the tool version, lockfile digest, and target platform.

Lock dependency resolution
Limit cache-directory growth
Keep a baseline build procedure after clearing the cache

Step 4

Import signing materials last

Import certificates, provisioning profiles, and unlock information only after validating the toolchain. Use a controlled directory and remove temporary copies when the task ends.

Record certificate validity scope
Limit keychain access principals
Validate the signing chain with an archive task

Acceptance criteria

The same commit must resolve dependencies, compile, test, and archive in a clean working directory. When it fails, the logs should identify the exact stage rather than only report “build failed.”

CI/CD integration

Add the physical node to your existing queue

The runner is an execution entry point, not a secret store, long-term artifact repository, or shared team directory. Define directory and permission boundaries before increasing concurrency.

Execution pipeline

Five stages, one auditable timeline

Record at least the commit, runner, start time, end status, and artifact location for every task. The node runs normally 365 days a year.

Register the runner

Register the executor with a dedicated automation account. Labels should describe system and task capabilities, not secrets or personal names.

Isolate the working directory

Give each pipeline its own work path. Delete temporary files after the task to prevent one build from contaminating the next.

Define the cache strategy

Name caches by lockfile and tool version, set capacity limits, and retain the complete execution path for cache misses.

Return build artifacts

Send archives, symbol files, and test reports to the team’s existing storage. The node’s working directory must not be the only copy.

Retain failure logs

Keep the failed stage, exit code, and key context. Remove tokens, keys, and signing materials before submitting a support request.

Concurrency control

Establish a single-task baseline first, then increase queue concurrency gradually. With 16GB RAM, test, archive, and inference jobs should be split according to their actual peak usage.

Retry boundaries

Retry only recoverable steps such as brief network interruptions. Preserve the original result when compilation, testing, or signing fails so the first error is not overwritten.

Artifact verification

After transfer, verify file size, digest, and task ID. Team members should be able to trace each artifact from the pipeline record to its commit and build environment.

MLX experiments

Validate the environment before scaling inference

NowMini M4 is well suited to reproducible, small-scale MLX experiments. Keep model files, run parameters, and result records separate for easy cleanup and reruns.

MLX CHECKPOINTS NOWMINI M4

Environment validation

Record the Python, MLX, and key dependency versions, then use a small tensor operation to confirm the environment runs correctly.

Model placement

Store model files in a dedicated data directory, verify their digests, and keep them separate from source repositories and temporary caches.

Run the task

Pin the model, input, sampling parameters, and random seed. Start with a small batch, then monitor memory and output stability.

Resource monitoring

Record peak memory, disk growth, runtime, and exit status to prevent logs or intermediate results from consuming all available space.

What to retain for each experiment

Input: Model ID, file digest, prompt or dataset version
Environment: System, Python, MLX, and dependency versions
Parameters: Batch size, generation length, sampling settings
Results: Runtime, peak resources, output summary, exit status

Storage boundaries

The base plan includes a 256GB SSD. Check available space before downloading models. Include large models, intermediate results, and multiple weight versions in your cleanup plan, or select a fixed storage add-on when ordering.

View plans and storage

Troubleshooting tree

Start with boundary conditions; do not change settings at random

First determine whether the issue is in the local network, access control, authentication, toolchain, or resources. Change one variable at a time and record the result.

Cannot connect to the node: which layer should you check first?

Confirm that the local network can reach external services. Disable temporary proxies that change routing, then test again.
Recheck the host address and node region in the console; do not use an address from an old screenshot.
Confirm that the current access source meets the restrictions, and check whether the local firewall blocks the target port.
Record DNS resolution, network reachability, and protocol handshake results separately instead of reporting only “cannot connect.”

Authentication failed: how to distinguish a username issue from a key issue

Check that the username belongs to the current node; do not reuse an account name from another server.
Check private-key permissions, file format, and the key path actually loaded by the client.
Verify that the host fingerprint matches the first record. If it changes, stop connecting and submit a ticket for verification.
Enable detailed client logging, retain authentication-method negotiation and the server rejection stage, and remove sensitive content before submitting.

Build failure: should you start with versions, dependencies, or signing?

First confirm that the Xcode, SDK, and command-line tools paths match the baseline.
Re-resolve locked dependencies in a clean working directory to determine whether the cache is contaminated.
Separate compilation from signing: complete a build without distribution signing first, then validate the archive.
Keep the first error and its context; do not capture only the summary at the end of the log.

Insufficient disk space: which directories should you check first?

Record total capacity, used capacity, and the change before and after the task. Do not immediately delete everything.
Check build caches, archives, test results, downloaded models, and steadily growing log directories in that order.
Clear the node copy only after confirming that the artifacts have been transferred, so the only recoverable files are not deleted.
Set capacity limits for caches and logs, and make cleanup part of the task completion workflow.

Task timeout: how can you tell whether it is slow or blocked?

Check the last valid log entry to determine whether the task is computing, waiting for the network, or waiting for a child process.
Check whether other tasks on the same node are competing for memory, disk, or a working-directory lock.
Set separate timeouts for downloading, building, testing, and uploading instead of using one total timeout for every stage.
Save process state and failure logs before retrying. If the issue is consistently reproducible, include the smallest task that reproduces it in the ticket.

Diagnostic record

Every effective investigation should capture five details

Time of occurrenceInclude the time zone
Node regionOne of the four available nodes
ProcedureRepeatable
Expected vs. actualDescribe the difference
Redacted logsRetain the error context

Secure operations

Make access part of the task lifecycle

Credentials are not files configured once and left unchanged forever. Recheck permission boundaries whenever people, runners, network sources, or projects change.

Rotate credentials

Rotate credentials immediately after team-member changes, suspected key exposure, or automation-account changes. Disable old credentials before validating the new ones to avoid leaving multiple unknown entry points active.

Restrict access sources

Prefer identifiable fixed egress. Revoke temporary access sources after the task and record who made the change, why, and the revocation result.

Minimize automation permissions

Give the runner a dedicated account and key with access only to the target repository, working directory, and artifact location. Do not let build scripts inherit personal long-term permissions.

Clean up for migration and handoff

Transfer source code, models, and artifacts first, then delete temporary certificates, keys, caches, and logs containing sensitive fields. The recipient should revalidate everything against the checklist.

Handoff completion criteria

The new owner can connect with their own authorization, run the baseline task, and read the logs; the former owner’s credentials are revoked; and no unattended temporary accounts or secret copies remain on the node.

Human support

Turn your issue into an actionable ticket

Submit existing-order issues through the console first. For pre-sales questions, bulk workflow reviews, or login problems, email us. These are the only external contact channels.

Ticket fields

Prepare these six items before submitting

The closer your information is to reproducible conditions, the more directly support can begin diagnosis instead of repeatedly confirming basic facts.

Order ID: The current order ID shown in the console
Node region: Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong
Time of occurrence: Include the date, time, and time zone
Reproduction steps: The sequence of actions from a working state to the error
Actual result: Error text, exit code, or unexpected behavior
Redacted logs: Retain context while removing passwords, keys, and tokens

Do not submit sensitive materials

Do not attach passwords, private keys, complete payment credentials, signing materials, or tokens that provide direct access to code repositories in tickets or email.

Existing-order issues

Sign in to the console and submit a ticket to associate the issue with the order and node. Suitable for connection problems, billing checks, node status, and existing task issues.

Submit a console ticket

Pre-sales and login assistance

Email support@nowmini.com with your workflow, target region, expected rental term, and reproducible issue. The email address may be displayed on its own line.

Email support@nowmini.com

Next steps

Once the configuration is clear, get started

Choose a NowMini M4 dedicated physical node to run builds, automation, and MLX tasks in Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong. Actual availability is based on the console’s real-time response.

Rent NowMini M4 now Contact the team