For connection issues, start with device status and credentials. For build issues, check Xcode, dependencies, and signing. CDNMac provides dedicated physical Macs, not virtual machines. Your project code, developer accounts, and signing assets remain your responsibility.
For existing orders, include your order ID, selected node, timestamps, and redacted logs. Device status and available actions are based on the latest information shown in the console.
Note whether the issue affects one device, one repository, one build, or every connection method.
Test the network, system access, toolchain, project dependencies, and signing separately. Avoid changing multiple settings at once.
Submit redacted logs, the expected result, and steps already tried. Never share private keys, tokens, certificate passwords, or full payment details.
Choose the category that best matches the main symptom, then gather the relevant details. Keep each request focused on one primary issue; mention related symptoms in your reproduction steps.
Share the device status in the console, the exact SSH or VNC error, your local network setup, when the issue first occurred, and whether only one access method is affected.
Include your Xcode and Command Line Tools versions, lockfile, failing command, target scheme, available disk space, and the first actionable error in the log.
Share the redacted signing error, bundle identifier, target environment, and certificate status. Never share certificate passwords, private keys, or usable tokens.
Include your ISP, network type, destination node, median from consecutive samples, and whether repository pulls or dependency downloads are also affected.
Include your order ID, rental period, base configuration, and the names of any SSD or Thunderbolt 5 daisy-chaining add-ons. Do not include full payment details in your ticket.
Note your current node, desired connection region, directories and build artifacts to keep, and whether you can redeploy the environment. Available options are shown in the console in real time.
Complete each step before moving on and note the result. Avoid changing keys, firewall settings, and your local network at the same time; otherwise, it’s hard to identify the cause.
Check the order and device status in the console, then confirm the current node and device ID. If the status is changing, wait for a stable result before testing the connection.
Use the system username, host address, and latest credentials for the current device. Don’t use connection details from another order.
From a trusted network, check whether the host and port are reachable, then verify key file permissions and authentication errors. Save timestamped errors, but never share private key contents.
If SSH works but the graphical session doesn’t, note the VNC client, connection stage, and screen status separately. This helps distinguish a session issue from a basic network problem.
Check whether your corporate network, VPN, egress rules, or local firewall block the destination port. Retest on another trusted network to see whether the issue is on your local connection.
A single ping only shows network round-trip time at that moment. It doesn’t indicate VNC responsiveness, download speed, or total build time. Retest with repeated samples and real workloads.
Build logs often contain cascading errors. Find the first actionable error that stopped the process, then check the related tool, dependency, signing, or disk requirements.
Record the full Xcode version, target platform, scheme, configuration, and tool path in use. The GUI and command line should use the same version.
Make sure the selected developer directory matches the expected version. After upgrading Xcode, check that command-line tools point to the right path so scripts don’t use an older one.
Keep the lockfile used by your project and note the dependency installation command and caching strategy. Test in a clean working directory before checking for cache corruption.
Check that the status, bundle identifier, target environment, and signing settings match. Share only redacted errors—never private keys or certificate passwords.
Check the space used by source code, dependency caches, DerivedData, archives, and exported builds. If space is low, start by clearing caches that can be rebuilt.
Keep the task start, first error, and task end timestamps. Note whether the failure occurred during dependency installation, compilation, archiving, signing, or export.
CDNMac M4 can run iOS builds triggered by your repository. When connecting GitHub Actions, GitLab CI, Jenkins, or another scheduler, treat the runner as a persistent build host, not a disposable container.
Use the repository, branch, and runner labels to decide whether to accept a job.
Use the lockfile and repository-specific cache, and record cache hits.
Pin the Xcode path, scheme, configuration, and export options.
Copy required artifacts, clear temporary directories, and keep redacted diagnostic logs.
Using consistent terms in your ticket makes it easier to distinguish physical devices, access protocols, automation runners, and deliverables.
A complete report makes issues easier to reproduce than a string of short messages. For sensitive fields, share only the type and status—not usable plaintext values.
Provide the order ID or device ID shown in the console so we can identify the model, rental period, and device record.
Name the node where your device is located; don’t just say “Asia” or “the US.” If you need to move, also tell us your desired connection region.
Include when the issue first occurred, when it most recently recurred, and when the task ended. Specify the time zone so we can match device and network records.
List the inputs, commands, target, and results in order. If the issue is intermittent, include how often it occurs and what triggers it.
Keep the relevant errors and timestamps, but remove private keys, tokens, certificate passwords, personal information, and full payment details.
Describe the expected status, file, or return value, and list the steps you’ve already tried that didn’t work.
Separate device and network issues from system access, toolchain guidance, and project responsibilities to avoid making changes at the wrong layer.
We can check device status, node-side networking, order details, and management status shown in the console, then investigate further using reproducible information.
CDNMac supportWe can help determine whether a device is reachable, whether credentials match the device, and whether SSH or VNC issues are at the network, authentication, or session layer.
CDNMac supportWe can help review Xcode, Command Line Tools, disk space, and build stages based on your logs. Your project team remains responsible for validating dependencies and scripts.
Shared troubleshootingYour team is responsible for project code, developer accounts, certificates, provisioning profiles, access keys, software licenses, dependency versions, and the lawful use of its workloads.
Your team’s responsibilityA dedicated device limits resource sharing, but doesn’t replace your team’s access controls. Keep clear checklists for first-time access, ongoing use, and the end of each rental.
Grant CI tokens, repository keys, and automation accounts only the permissions each task needs. Don’t let multiple projects share the same high-privilege credentials long term.
Keep a key and token rotation log. Revoke access promptly when team members, repositories, or job boundaries change.
Check certificate and provisioning profile status regularly, and remove unused copies to prevent pipelines from selecting outdated settings.
Before your rental ends, copy source changes, build logs, archives, and required artifacts to storage controlled by your team. Check that the files are readable.
Include your order ID, node, timestamps, reproduction steps, redacted logs, and expected result. Never send plaintext keys, tokens, or certificate passwords.