Find answers about models, regions, billing, access, permissions, and offboarding. Each order maps to one dedicated Apple Silicon physical node, with no shared compute resources.
Let’s clarify ownership: OrbVPS provides dedicated Apple Silicon physical nodes, not virtual machines divided by shared capacity.
Each active order maps to one physical Mac with a specified configuration. Its processor, memory, and system drive are not allocated to other tenants during the rental term, and the machine is not split into multiple virtual instances for sale. The hardware details, system load, and temperature data you see come from that node itself.
The node runs in a remote facility and provides SSH command-line access and a VNC graphical interface over the network. Teams can run Xcode, build scripts, self-hosted runner jobs, automated tests, and local model workloads suited to the configuration without keeping the device in the office.
No. The service provides a dedicated physical machine. The system runs on actual Apple Silicon hardware rather than a virtual instance on a shared host. For multi-system testing, plan disks, toolchains, and rollback baselines within the node instead of assuming virtual machine snapshots can be copied on demand.
Typical uses include continuous Xcode builds, iOS and macOS automated testing, React Native packaging, self-hosted runner jobs, remote video editing, and small AI experiments. Nodes suit workloads that need persistent dependencies, caches, certificates, and build logs, but not unassessed high-risk scripts exposed directly to the public internet.
The catalog contains only these three tiers. Memory and internal storage are fixed; additional storage can be selected separately at checkout.
Suitable for single-repository Xcode builds, lightweight iOS CI/CD, command-line tasks, and low-concurrency automated testing. Estimate the space needed for DerivedData, dependency caches, and build artifacts before use.
Choose Orb M4 16Suitable for dependency-heavy projects, medium-scale React Native packaging, parallel testing, and continuous builds that retain more cache. A balanced choice for most stable team pipelines.
Choose Orb M4 24Suitable for large projects, multitask builds, heavier macOS testing, video workflows, and controlled small-model experiments. Verify software versions, concurrency, and disk growth before deployment.
Choose Orb M4 ProSingapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong offer all three model tiers. Every catalog combination is marked as available.
Suitable for builds and remote access across Southeast Asian teams. Select this region directly at checkout.
Choose a Singapore nodeSuitable for Xcode builds, testing, and remote workflows for teams in Japan and East Asia.
Choose a Japan nodeSuitable for continuous builds and automated testing for teams in South Korea and Northeast Asia.
Choose a South Korea nodeSuitable for cross-region development collaboration and remote access between South China and Southeast Asia.
Choose a Hong Kong nodePrioritize the region closest to your code repository, CI service, artifact storage, and primary operators’ network paths. Before migration, test SSH round-trip time, repository pulls, and artifact uploads rather than judging the full workflow by map distance alone.
“Available” means the model and region combination is normally orderable. Actual availability when you submit the configuration is determined by the console in real time. The current result shown by the console is authoritative.
Changing regions does not relocate the existing physical device. You generally need a new order in the target region, then migrate repositories, toolchains, cache policies, and business data before ending the original node rental. Keep a rollback backup during migration.
All prices are shown in US dollars (USD). Before confirming an order, the model, region, term, and add-ons are displayed clearly.
Suitable for short-term validation, one-off builds, and pre-migration testing. A short term does not eliminate the need to back up data and revoke credentials.
Suitable for sprint phases, release weeks, and compatibility testing lasting several days, reducing the need for daily confirmations.
Suitable for stable CI/CD, fixed build nodes, and team workflows that retain dependency caches over time.
Suitable for long-running tasks with a verified model, region, and toolchain. Confirm capacity planning and the internal renewal owner before ordering.
The console shows the current rental term and expiration status. If you need continued access, renew before the term ends and verify the resulting order. Do not schedule critical builds beyond the term boundary without checking renewal status.
Available terms and configurations are determined by the console at that time. Before changing anything, verify the new term, model, region, and add-ons, then submit after confirming the details. Existing order records are not rewritten by later selections.
The base amount depends on the model and rental term. Optional SSD storage or Thunderbolt 5 parallel operation is added for the selected term. Configuration details are shown before payment, and all amounts are in US dollars (USD).
OrbVPS supports USDT-TRC20 and Visa / Mastercard / Amex processed by Stripe. All orders are billed in US dollars (USD).
Pay using the details shown on the checkout page, and verify the network and order amount.
Card payments are processed by Stripe; the gateway currently available is determined by the console.
No. The only published payment methods are USDT-TRC20 and Visa / Mastercard / Amex processed by Stripe. Never pay an address or account not shown on the order page.
Models, terms, add-ons, and order totals are recorded and settled in US dollars (USD). The page does not automatically convert amounts into other currencies.
Save the order number, payment time, amount, and verifiable transaction record, then sign in to the console and submit a ticket. Never send full card details or unredacted sensitive credentials in a ticket.
After activation, confirm the node address, host fingerprint, and access credentials before connecting repositories, build tools, and CI jobs.
Connect using the address and port provided by the console. Verify the host fingerprint on first login; private key permissions should generally allow read access only to the current user.
The graphical session is suited to the Xcode interface, display settings, and desktop tools. After a disconnect, reconnect to the existing session instead of starting unnecessary graphical processes again.
The node supports administrator operations required to install development tools, configure services, and make controlled system changes. Record a baseline before changes and avoid disabling essential access services.
Use a separate working directory, clear labels, and the minimum required credentials for the runner. After connecting it, run controlled tests before gradually migrating production pipelines.
Add the new public key to the authorized list first. Keep the old session open, then use a second terminal to verify that the new key works. Remove the old key only after confirmation, and record the rotation time. Deleting it first could remove your remote access.
Stop builds, databases, or artifact tasks that are still writing. Confirm caches and logs have been flushed, then initiate the restart from the console. After recovery, check SSH, VNC, disk mounts, runner status, and key build-tool versions in order.
Check the node network, runner process, service startup method, working-directory permissions, registration status, and task concurrency in order. If it remains offline after restarting the service, collect the node ID, incident time range, service status, and relevant logs, then submit a console ticket.
These terms directly affect selection, access, and build troubleshooting. Aligning definitions reduces back-and-forth in support tickets.
Copy code repositories, build artifacts, signing materials, logs, configuration files, and any cache indexes that must be retained.
In another environment, selectively extract or check out critical content to confirm file integrity, correct permissions, and access to required keys.
Remove SSH public keys, runner registration tokens, repository deployment keys, and temporary credentials used by automated jobs.
Remove the node from CI queues, monitoring, artifact uploads, and scheduled jobs to prevent work from being sent after offboarding.
Dedicated access does not mean automatic backups. Establish backup policies for code, keys, build artifacts, and business data when the node is activated.
No. Treating node contents as backed up is not automatic. Based on your recovery objectives, copy repositories, configuration, keys, databases, build artifacts, and essential logs to a controlled location, and regularly test recovery.
At minimum, migrate unpushed code, signing and build configuration, required artifacts in CI working directories, project dependency manifests, environment version records, and troubleshooting logs. Run a recovery test after migration instead of only confirming that files were copied.
Repository keys, runner tokens, and service credentials used on the node may still grant access. After migration, revoke or rotate them with the corresponding services and remove automated jobs that still point to the node.
After service ends, the node enters the access-revocation and data-processing workflow. You must complete migration and verification before the rental term ends; the post-rental processing workflow is not a data recovery plan. To check a specific order, sign in to the console and submit a ticket.
Choose a model, region, and rental term, then place your order. For an existing order, sign in to the console and submit a ticket with the node ID and incident time range.