Start here:
your answer is probably below

Shell M4 comes with M4, 16 GB, and 256 GB storage. It’s a good starting point for testing single-project builds, command-line packaging, or low-concurrency CI. Whether it’s enough depends on how many projects you keep open, simulators you run, and whether you also use containers or other services.

Run a full build with your actual repository, then check memory pressure, swap usage, and free disk space. If memory pressure stays high, reduce concurrency first. If that still disrupts your workflow, consider the M4 / 24 GB / 512 GB configuration in Shell M4 Plus. Don’t judge the whole configuration by the time taken for a single incremental build.

Shell M4 Pro comes with M4 Pro, 64 GB, and 2 TB storage. Consider this tier for running multiple builds at once, working with large dependency and artifact sets, or MLX and llama.cpp experiments that need more unified memory.

Whether a model fits also depends on quantization, context length, runtime caches, and memory used by other processes—not just the model file size compared with 64 GB. Track peak memory and real-world throughput before committing to a long-term rental. We don’t guarantee a specific model size or build speedup.

Assess compute and storage needs separately. If the chip and memory are adequate but multiple Xcode versions, build caches, or artifacts are filling the disk, consider adding a 1 TB or 2 TB SSD. Extra storage won’t increase unified memory or turn an M4 into an M4 Pro.

If your workload needs M4 Pro and 64 GB of unified memory, choose Shell M4 Pro with its included 2 TB. Before ordering, check the added capacity, billing period, and mounting arrangements. Keep a separate backup before moving files; extra capacity doesn’t include automatic migration or backup services.

Each of the four rental periods has its own listed price; quarterly pricing isn’t simply the daily rate added up. The table below compares the standard daily and quarterly prices for all three tiers, so you can weigh a short trial against ongoing use. See the plans page for full weekly and monthly prices and add-on rates.

A longer rental period lowers the cost per period for ongoing use, but commits you to a longer term upfront. For a one-off release, environment check, or archive, consider a daily rental. For a persistent runner, compare your expected usage with any add-on costs.

Open the relevant order in the console to see available renewal, configuration change, and add-on options. Check the order’s confirmation details for when changes take effect, whether migration is involved, how the paid term is handled, and any additional charges. Don’t estimate a prorated difference from the daily rate.

If the option you need isn’t available, sign in to the console and submit a support ticket with your order number, preferred period, and requested configuration. Back up your data before changes involving the model or disk, then confirm the implementation plan. Submitting a request doesn’t mean the change is complete.

A successful payment doesn’t necessarily mean auto-renewal is enabled. Check the order’s renewal settings, billing status, and expiry date in the console, and rely on the actual authorization and confirmation. If your pipeline needs to keep running, check well before expiry rather than waiting for the connection to drop.

Billing is based on the rental period you purchased, not CPU usage. Closing an SSH session, stopping a runner or build, or leaving the Mac idle won’t cancel the order or change its expiry date. Use the order options in the console to adjust a future rental period.

Models, rental periods, and add-ons are listed in US dollars (USD) so you can compare the same configuration across locations. The $ symbol on this page means USD. Before ordering, check the base rental price, add-ons, and total due.

If your card account uses a different billing currency, your card issuer handles conversion and any related fees; these aren’t part of ArmShell’s listed prices. For USDT-TRC20, follow the network, amount, and payment details shown on the payment page. Don’t substitute another network.

Choose from Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East. All three tiers are available in these five locations; check the console for real-time availability when you order.

If you use a graphical desktop often, test responsiveness from your primary work network. For CI workloads, also consider routes to your repository, dependency sources, and artifact destination. Distributed teams should choose based on where jobs primarily run, not just where one team member is located.

Not sure? Use a short rental to test the full workflow: clone the repository, restore dependencies, build, and upload the artifacts. A single ping test can’t tell you how all four steps will perform.

Get the connection address, port, and credentials from the console once your Mac is ready. “Dedicated physical Mac” describes how computing resources are assigned; it doesn’t guarantee a static public IP, dedicated egress, or an address that never changes.

If your repository, firewall, or compliance process requires a dedicated address, an egress allowlist, or a static IP, contact support before ordering. Specify whether you need an inbound connection address or an outbound egress IP, and confirm that the location can meet your requirements. Don’t pre-allow an address based on a hostname in an example command.

Latency varies with your ISP, routing, time of day, and local network. A reference ping time isn’t a guaranteed result for your connection. ICMP round-trip time, SSH command response, and remote desktop smoothness are different metrics.

First, confirm the connection address and port in the console, then check your local network and firewall. Compare different times on the same network, noting whether timeouts occur during connection, dependency downloads, or file uploads. Include these details in a support ticket to make troubleshooting easier than simply reporting that it’s “slow.” Nodes operate year-round, 365 days a year, but end-to-end connectivity still depends on your network.

Don’t treat post-expiry retention as a backup promise. Export your data before the order expires and check the order’s data-handling notices in the console. Contact support about retention arrangements and erasure progress for your order; we don’t guarantee a standard number of days for recovery.

Once a node is reclaimed, the previous user’s data is handled according to the applicable process. Data that has been erased can’t be recovered by renewing. Before you stop using the Mac, sync your files, verify that your backup is readable, and revoke any repository credentials, runner registrations, or other access tokens you no longer need.

During your rental, you use a dedicated physical node; its CPU, GPU, and unified memory aren’t shared with other customers. ArmShell won’t access user files or workloads on the node without authorization. If you need troubleshooting help, describe the issue in a support ticket and share logs or grant access only as needed.

A dedicated machine doesn’t replace good account and access management. Give each team member a separate system account and SSH key instead of sharing a long-term password. Grant access only to the directories and repositories they need. Never expose private keys, signing passwords, or active tokens in support tickets, screenshots, or build logs.

Use three types of backup: commit code to your repository; document build scripts, tool versions, and environment settings so you can recreate them; and save artifacts and essential working files off the node with rsync or another controlled transfer method. Store sensitive credentials using a secure method approved by your team.

Copying files to another directory on the same node isn’t an independent backup. After the first backup, spot-check files, verify checksums, and try rebuilding the environment from a copy. Before expiry, run one more incremental sync and confirm the local copy includes the latest build results.

We accept USDT-TRC20 and Visa, Mastercard, or Amex card payments via Stripe. All payments are in US dollars (USD). Available payment gateways are determined by the response from our backend.

For card payments, follow the verification steps at checkout. For USDT-TRC20, check the network, amount, and recipient details carefully. Don’t resend a payment to an address from an old order or assume a screenshot means a new order is active; check the status in the console.

First, check the billing and order status in the console to avoid paying twice because the page hasn’t updated. If you still can’t confirm the status, submit a support ticket in the console or email support@armshell.com with your order number, payment method, amount, and either the card billing reference or the USDT-TRC20 transaction hash.

Never send your full card number, card security code, system password, or private key. Support will check the order and payment records. Payment receipt, verification, and node activation are separate steps; completion of one doesn’t confirm the others.