Find the next step

Start here, then get in touch

Check the order for delivery, the port for connectivity, and the logs for build failures. Search a keyword to find troubleshooting steps you can follow right away.

Enter a keyword to see matching articles. After searching, press Enter to jump to the first result.

For an issue with an existing machine, add the details to the same ticket so troubleshooting can continue in one place.

Choose where the issue occurs

We cover four areas separately. First make sure the machine is reachable, then check the toolchain and signing setup. This helps avoid mistaking a network issue for a build failure.

01 / Handoff

Startup & delivery

Check order progress, find your credentials, and verify status and connection details.

Check delivery
02 / Access

Remote access

Troubleshoot SSH timeouts, rejected public keys, and desktop connection failures.

Fix connection issues
03 / Builds

Xcode & signing

From archive logs to provisioning profile mismatches, identify whether the issue is in compiling, archiving, or exporting.

Troubleshoot builds
04 / Billing

Billing & renewals

Check the listed daily, weekly, monthly, and quarterly prices, renewal options, and payment status.

Check billing
Complete the machine handoff

Use the order status to track delivery

Payment, order processing, and machine delivery are separate steps. After paying, check your order rather than assuming the machine is ready to connect based on the payment page alone.

  1. 01

    Confirm payment

    In the console, check the order number, model, rental term, and payment status. A submitted on-chain transfer or card payment does not necessarily mean the order status has been updated.

  2. 02

    Check delivery status

    Open the relevant order or instance details to see the current progress. The console provides the latest delivery timing and availability status.

  3. 03

    Get your connection details

    Once the machine is delivered, find the hostname, username, SSH port, and first-login details in the instance page. Use the values shown for that instance; do not reuse settings from another order.

I’ve paid. Why aren’t my connection details available yet?

First make sure you’re viewing the order for this payment, then check its payment status in the console. If payment is confirmed but the instance is still processing, include the order number, payment method, payment reference, and current status in a support ticket. This gives the team the details needed to check delivery.

For USDT-TRC20, keep the transaction hash. For card payments, keep the payment reference. Never send your full card number, security code, or console password, and don’t create another order for the same payment.

SSH times out or rejects my public key. What should I check?

Connection timed out: First check that the instance has been delivered and is ready to connect. Then verify the hostname and port character by character, and check your local network, proxy, and access rules. A timeout occurs before authentication, so changing keys repeatedly is unlikely to fix a network path issue.

Permission denied (publickey): Check that the username, private key, and public key registered in the console match. Upload the contents of the public key file; keep the private key on your own device and never send it to support. Replace HOST, PORT, and USER below with the values shown in the instance details.

ssh -vv -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519 \
  -p PORT USER@HOST

Before sharing diagnostic output, remove sensitive details such as the hostname and personal file paths. Keep the error type and authentication stage. If the host fingerprint changes, check whether the system was recently reinstalled rather than disabling fingerprint verification.

SSH works, but remote desktop won’t open. What next?

Check the desktop connection details in the instance page and make sure you’re connecting to the same machine. Remote desktop and SSH use separate connection paths, so a successful SSH connection only confirms that the SSH path is reachable.

Follow the connection instructions to verify the desktop service, access port, and tunnel destination. If you see a black screen, note the client message and the steps that led to it. Then try lowering the resolution or image quality to help distinguish a display issue from an authentication failure. Before restarting, stop any archive or test currently in progress.

See SSH and remote access for connection settings and migration steps. Open the desktop connection from the instance details after signing in.

Find the first real error

An archive failed? Don’t wipe everything first

Preserve the failure details, then check Xcode, the Scheme, dependencies, and target platform. The final failure summary is only the outcome; the first compile or signing error is where to start.

What’s the right order for troubleshooting an archive failure?

Record the current commit, build command, and Xcode version. Confirm that the Scheme exists and is configured for archiving. For command-line builds, also check the selected developer directory so the version used by CI matches the one open on your desktop.

xcode-select -p
xcodebuild -version
xcodebuild -list -workspace App.xcworkspace

Replace App.xcworkspace and App with your project’s actual names. If your project uses a workspace, don’t pass a project file by mistake. Missing dependencies, an uncommitted shared Scheme, or a deployment target that doesn’t match the SDK can all cause failures before archiving starts.

set -o pipefail
xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -archivePath "$PWD/output/App.xcarchive" \
  archive 2>&1 | tee archive.log

This produces an .xcarchive, not a distributable IPA. If archiving succeeds but export fails, check signing and provisioning profiles rather than rebuilding all dependencies.

When should I troubleshoot DerivedData?

Investigate the cache if you see module cache incompatibilities after switching toolchains, inconsistent generated files, or a build that succeeds in a clean environment but fails with an existing cache. Stop the project’s builds and save the logs first; don’t use the entire user directory as a cleanup target.

A safer test is to set a new, project-specific directory for this build. Keep the old directory for reference. If the build still fails with the new directory, continue checking the source, dependencies, or configuration instead of clearing the cache again.

xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -derivedDataPath "$PWD/.build/DerivedData-check" \
  -destination 'generic/platform=iOS' \
  build

Once the build works, clean up only the old project directories you’ve confirmed are no longer needed. Keep source files, signing assets, archives, and DerivedData separate to reduce the risk of deleting the wrong files.

Can’t find a simulator runtime or test destination?

First check whether you’re archiving for a device or running simulator tests. A device archive requires an iOS device destination; simulator tests require a runtime and device supported by your Xcode version. Don’t use a simulator destination for a distribution archive.

xcrun simctl list runtimes
xcrun simctl list devices available
xcodebuild -showdestinations \
  -workspace App.xcworkspace -scheme App

If a runtime is missing, install the relevant platform component in Xcode settings. Xcode versions that support the command below can also download the iOS platform component this way. Check available disk space first, and make sure the command line is using the Xcode version you intend to use.

xcodebuild -downloadPlatform iOS

After installation, list the destinations again and update CI with an available destination. Don’t keep using a simulator device ID copied from another machine.

Handle signing assets separately

Certificates, profiles, and API keys each have a role

A .p12 contains a certificate and private key; a provisioning profile specifies the app and its capabilities; an API key authorizes certain API requests. They aren’t interchangeable.

Why can’t CI find my signing identity after importing a .p12?

Transfer the .p12 to the machine over a secure channel, import it into the keychain used for builds, and confirm that it contains the matching private key. A certificate without its private key can’t sign code. Provide the import password through a CI secret; don’t put it in your repository, build script, or support ticket.

security find-identity -v -p codesigning

Run the check in the environment used by the runner. Seeing the certificate as a desktop user doesn’t mean another service user can access it. Also check that the keychain is unlocked, included in that user’s search list, and accessible to the signing process.

Use a dedicated keychain for builds and lock it according to your process when the job ends. If you need help, share only redacted identity check results and error text. Never send the .p12 file, private key, or import password.

Archive succeeded, but IPA export reports a provisioning profile mismatch?

Check four things: the Bundle ID, Team ID, export purpose, and entitlements. For apps with extensions, every Target that needs signing must have a matching configuration; a match for the main app doesn’t guarantee that the extensions are configured correctly.

Next, check that the provisioning profile is valid, includes the certificate in use, and matches the signing method selected for export. Development and distribution builds use different configurations, so don’t choose a profile based only on a similar filename.

Keep the export-stage logs and a redacted copy of ExportOptions.plist. In your support ticket, say whether the failure occurred during archive or exportArchive to narrow down the issue.

How should I store an App Store Connect API key?

Store the .p8 file in a restricted-access directory, and provide the Key ID, Issuer ID, and file path through CI secrets. Grant only the permissions needed for uploads or automation. Don’t put the key contents directly in a lane or commit them to your repository.

An API key can be used for upload and management workflows that support this authentication method, but it can’t replace the certificate and private key required for local code signing. If a TestFlight upload fails, first determine whether the problem is local signing, API authentication, app permissions, or version information.

After rotating a key, update the runner configuration and remove old references. If you need support, share the redacted error code and the stage where it occurred—not the .p8 file.

What should I check when setting up Fastlane match on a new machine?

Check access to the signing repository, the decryption password, distribution type, app identifier, and team configuration. For routine CI runs, use read-only access to fetch prepared signing assets rather than creating or modifying certificates every time.

lane :prepare_signing do
  match(
    type: "appstore",
    readonly: true,
    app_identifier: ENV.fetch("APP_IDENTIFIER"),
    team_id: ENV.fetch("TEAM_ID")
  )
end

Manage repository credentials separately from the decryption password. If fetching fails, check repository authentication. If decryption fails, check the password. If installation succeeds but signing fails, check the keychain and provisioning profile. Don’t lump all three issues together as “match isn’t working.”

Check rental terms and payments separately

Four billing cycles, listed prices

Daily, weekly, monthly, and quarterly terms are priced separately; the daily rate is not simply multiplied to calculate other terms. Both models are dedicated physical machines, not virtual machines. The checkout summary shows the final order amount.

Base model list prices in US dollars (USD)
Model & specsDayWeekMonthQuarter
OSXBuild Bake M4
M4 / 16GB / 256GB
$20.1$54.2$100.3$272.8
OSXBuild Bake M4 Pro
M4 Pro / 64GB / 2TB
$60.3$162.9$301.6$820.4
How do I compare rental terms and add-ons?

Choose a term based on how long you expect to use the machine, then check the model price and add-ons for that same billing cycle. The order shows the exact start and end times; a “month” doesn’t simply mean the remaining days in a calendar month.

Additional SSD storage and Thunderbolt 5 daisy chaining each have listed prices for all four billing cycles. Select the options you need in the configurator, then review the checkout summary. Don’t estimate the final bill from the base model price alone. See rental plans and add-ons for the full catalog and guidance.

Where do I renew, and what should I do before my term ends?

Sign in to the console, open the relevant subscription or order, and check the expiry date, renewal options, and billing status. After paying, confirm the new expiry date. Opening the payment page or submitting a payment doesn’t necessarily mean the renewal is active.

Check the order settings and status to see whether automatic renewal is enabled or there’s an outstanding invoice. If you want to keep using the machine, renew in advance and confirm the result. If you’re ending the rental, export your source code, build artifacts, and any configuration you need ahead of time.

When the rental term ends, the machine enters the recovery process, and its disk is securely erased before the system is reinstalled. Don’t use the node as your only backup or wait until after expiry to retrieve local files.

Which payment methods are supported, and what if a payment fails?

We accept USDT-TRC20 and Visa / Mastercard / Amex (via Stripe), all billed in US dollars (USD). Available payment gateways are determined by the response from the backend.

For USDT-TRC20, check the network, receiving address, and amount on the checkout page. Don’t reuse payment details from an old order. For card payments, follow the gateway’s verification steps, then return to the console to confirm the status.

For a payment issue, provide the order number, payment method, redacted message, and transaction reference. Card processing is handled by Stripe; you don’t need to include your full card number or security code in a ticket or email.

Include what happened

Before submitting a ticket, check these four things

Reproducible steps are more useful than “the build failed.” If a task is still running, save its state before restarting or changing the configuration.

  • Restarted after saving the current state

    Stop builds and tests, save logs and any uncommitted files, then restart the machine. Note what changed before and after the restart. If the current task can’t be interrupted, say in the ticket that you haven’t restarted and why.

  • Verified the SSH port and public key

    Compare the hostname, username, port, and key pair with the current instance details. Include the exact error text, but never upload a private key or send the first-login password.

  • Included the last 50 lines of the log

    Include the last 50 lines and context around the first relevant error, along with the command, Xcode version, and commit ID. For long logs, attach them to a console ticket after removing tokens and signing secrets.

  • Included the node and order number

    Provide the order number, node, time and time zone of the issue, expected result, and actual result. Also mention when it last worked as expected to avoid repeated questions about basic details.

Extract the last lines of a log without changing build artifacts:

tail -n 50 archive.log

Never include certificate private keys, .p12 passwords, .p8 files, access tokens, or console passwords in support materials.

Still stuck? Send us your findings

For an existing order or machine issue, sign in to the console and submit a ticket. For pre-sales questions, sign-in issues, or other contact requests, email us at support@osxbuild.com.

Support is coordinated across Asia-Pacific and US West Coast time zones. Follow progress through your ticket or email. Include your time zone and the times you’re available to troubleshoot, and add new findings to the original ticket.

Our contact page explains what information to include for different enquiries. Machines run 365 days a year; ticket response hours are separate from node availability.