Each Apple Silicon physical node is assigned to a single tenant. It is not a virtual machine, and its CPU, GPU, and unified memory are not shared with other tenants.
Review isolation, access, and data handling before moving your engineering and build workloads.
Having trouble reaching a node on an existing order? Sign in to the console and open a support ticket with your order number and the time the issue occurred.
An availability target and historical measurements are not the same thing. Here we explain the service target and how it is calculated—we don’t present a target as a measured result.
Monthly availability target
99.9%
All nodes operate year-round, 365 days a year. If monthly availability falls below 99.9%, your rental is extended in proportion to the verified downtime.
The teal marker represents the service target, not daily monitoring results.
We review node reachability, outage start and recovery times, and the related orders. This page does not publish verifiable daily monitoring records, so we don’t show an all-green daily status bar or claim that everything was operational throughout the past 90 days.
Monthly availability is calculated as (total service time for the month minus verified downtime) divided by total service time for the month. When submitting a request, include the time of the incident and your time zone. You don’t need to guess at the cause; the original connection error is more useful than simply saying “I can’t connect.”
Interruptions caused by your own actions and events beyond our reasonable control are handled as defined in the Terms of Service. A single SSH timeout does not, by itself, prove that a node was unavailable; we assess it alongside the connection method, network path, and node records. See the Terms of Service for the applicable scope.
Dedicated hardware prevents resource contention between tenants. You’re still responsible for managing permissions, team collaboration, and concurrent workloads on the machine.
Each order comes with a dedicated physical machine, not a virtual instance carved out of a shared host. Other tenants don’t use its CPU, GPU, or unified memory, and they don’t share your macOS environment.
The full macOS GUI and command line are available. Xcode, simulators, and Metal run in a native environment. Multiple builds, tests, or inference jobs you launch still compete for resources on the same machine.
If your team takes turns using a node, manage system accounts, SSH public keys, and project directory permissions for each member. Dedicated access doesn’t mean everyone should have administrator privileges, and it doesn’t make sharing a private key safe.
When evaluating performance, also record project size, Xcode version, number of concurrent jobs, and cache state. Dedicated hardware means no contention with other tenants; it does not guarantee a fixed build time for every workload.
When a rental ends, the disk is erased and the system is reinstalled before the machine is assigned to the next tenant. Nodes are not long-term archives, so keep backups separate from the rented machine.
Back up uncommitted code, build artifacts, necessary configuration, and key material to storage you manage. Check that the backup opens and that you can clone the project again; don’t just check whether the copy command completed.
Remove runner registrations you no longer use and revoke deployment tokens and repository access. Erasing the disk removes local data; it does not revoke credentials in external systems.
When the rental ends, the disk is erased and the system reinstalled before the machine is assigned to the next tenant. Don’t rely on an expired rental as a way to recover project files.
First, code and large files: confirm that Git commits and large file objects have synced. Second, work products: archive packages, test reports, logs, and build outputs that haven’t been uploaded. Third, rebuildable environments: dependency lockfiles, tool versions, and CI configuration. You don’t need to keep every cache you can recreate, but export anything that can’t be rebuilt.
We don’t read files or project data on tenant nodes. Account, order, and payment transaction identifiers are service management records and are handled separately from project files on the node. See our Privacy Notice to learn why we collect information and what rights you have.
SSH key authentication is the only sign-in method used by default. You can review connection credentials and order-related activity in the console after signing in, and reset credentials as needed.
Generate a key on your own client, keep the private key there, and provide only the public key. On first connection, verify the node details and host key fingerprint. If the fingerprint changes, first check whether the system was reinstalled—don’t ignore the warning.
We recommend protecting your local key with a passphrase. Never put a private key in a repository, build log, or support ticket, and don’t share the same private key among team members.
When someone leaves a project, remove their public key and any account permissions they no longer need. Give CI its own service account and tokens, and manage repository, build, and deployment permissions separately.
Open only the ports you actually need. After resetting credentials, check whether old clients, automation scripts, or runners still use the previous configuration. This helps prevent repeated failed connections from obscuring the real issue.
In a support ticket, you can include a public key fingerprint, client version, error text, and redacted configuration snippets. Never share passwords, SSH private keys, full access tokens, or environment variables containing secrets. If troubleshooting requires temporary access, agree on the scope and revocation process in the ticket first.
All orders are settled in US dollars (USD). Only the following two payment methods are supported. Available payment gateways are determined by the response from our backend.
Card payments are processed by Stripe, and we don’t store card numbers. To reconcile an order, we use the relevant transaction identifier and payment status. You don’t need to send a full card number or card security code by email or in a support ticket.
If a charge fails or the payment status doesn’t look right, provide your order number, the time it happened, the amount, and the error shown on the page. Redact personal information from screenshots, and don’t make repeated payments to test the status.
Payments are verified against on-chain records. Before sending funds, make sure the network, recipient address, and order amount match the checkout page. We use the transaction hash to verify payment; never provide your wallet’s private key or recovery phrase.
If your order status hasn’t updated after you send a transfer, keep the transaction hash and order number, then open a support ticket. We don’t promise a fixed confirmation time, and a screenshot is not a substitute for the transaction record.
Node files, account records, and payment transaction identifiers are separate data categories. When reporting a payment issue, include only information related to the order—don’t attach project archives or signing material.
Send security reports to support@xcodenode.com. For node issues on an existing order, you can also sign in to the console and open a support ticket.
Identify the affected page, order, or node, and describe what you observed. Without evidence, don’t present a suspected data leak as a confirmed incident.
List the inputs, expected results, and actual results in the order you performed the steps. Test only within areas you’re authorized to access, and don’t read other tenants’ data.
Include the time and time zone, along with redacted error text or screenshots. Remove tokens, passwords, private keys, and personal information while keeping relevant context.
Send additional details by email or support ticket, and follow up in the same thread. Issues that affect access, such as an unreachable node, are investigated as a priority. We’ll share updates in our reply.
Don’t include secrets that could be used to access a node directly. If you suspect credentials have been exposed, revoke the relevant tokens, remove any unexpected public keys, or reset credentials first. Then preserve the necessary records and report the issue.
Choose a dedicated physical node, and have your keys, backups, and team permissions ready. Plans, rental periods, pricing, and add-ons are listed on the plans page.