Service-side boundary
We provide the dedicated physical machine, physical node, order status, and clearly defined remote access entry point.
Every OakVPS rental maps to one dedicated physical Cloud Mac. It runs on a clearly identified physical node and is accessed through the remote entry provided with the order, without sharing a virtual-machine resource boundary with other renters. The platform manages the service entry point and infrastructure; your team manages accounts, keys, developer credentials, project data, and member permissions.
We provide the dedicated physical machine, physical node, order status, and clearly defined remote access entry point.
Manage login credentials, SSH keys, member permissions, development certificates, tokens, and project data.
Export deliverables and logs during the rental term, complete backups, and remove sensitive material according to your team’s policy.
Physical resource isolation defines device ownership; your team must still manage accounts, keys, network sources, and project data continuously.
Each rental maps to a dedicated physical machine. The ordered model, node, and term define the current scope; the physical node is not presented as a shared virtual-machine instance.
Verify the host fingerprint, use key-based authentication, restrict credential distribution, and ensure each member receives only the minimum access needed to complete their work.
Users manage code, models, certificates, logs, and build artifacts. Complete backups, exports, access revocation, and sensitive-data cleanup during the rental term.
| Security object | Provided by OakVPS | Managed by your team | Recommended checks |
|---|---|---|---|
| Physical device | Dedicated physical machine and physical node assigned to the order | Choose the right configuration and rental term for the workload | Model, node, term, and add-ons |
| Remote access | Connection parameters provided in the order details | Protect credentials, verify the fingerprint, and restrict sources | Username, port, and host fingerprint |
| Development environment | Available macOS graphical and command-line environments | Manage dependencies, certificates, tokens, and repository permissions | Version, permissions, logs, and available disk space |
| Project data | Device workspace available during the rental term | Back up, export, delete, and hand off | Artifact verification, backup readability, and cleanup records |
Shared accounts obscure ownership of actions and increase risk when team membership changes. Start your access policy with individual identities, least privilege, and timely revocation.
Do not reuse the console password for code hosting, email, or other development services. Store it in a controlled password manager.
For remote command-line access, prefer locally generated SSH keys. Keep private keys only on controlled devices and never send them through chat.
When collaboration requires multiple users, create distinguishable access methods for each member instead of distributing one long-lived credential set to the whole team.
When a member leaves, changes roles, or loses a device, immediately remove the associated public keys, tokens, and repository permissions.
Signing certificates, private keys, access tokens, and repository credentials should each have a defined purpose, owner, import time, and cleanup action.
Confirm that the credential is required for the current task. Prefer material with narrower permissions and a shorter validity scope, and record its owner.
Restrict file permissions. Do not write credentials into repositories, build logs, command history, or publicly downloadable artifact directories.
Remove temporary material according to team policy, revoke tokens that are no longer needed, and check repository status, cache directories, and artifact packages.
Before submitting troubleshooting details, redact private keys, certificate passwords, access tokens, complete payment credentials, and connection parameters that could be reused directly.
A remote entry point is not a channel to configure once and ignore forever. Recheck connection conditions whenever you change your local device, network environment, or team members.
Save the host fingerprint on the first connection. If it changes, stop and verify the order details instead of bypassing the warning.
Whenever possible, connect from team-managed devices and trusted networks. Avoid saving keys or session information on public devices.
Before transferring sensitive material, confirm the target path, file permissions, and recipient. Do not mix credentials into ordinary project archives.
Before leaving the device, sign out of graphical sessions and command-line connections, close unneeded forwarding, and remove local temporary copies.
1. Read the host and port from the order
2. Compare and save the host fingerprint
3. Check local private key file permissions
4. Connect with the specified username
5. Verify system and disk information
6. Record the owner of this connection
When a connection fails, check the username, port, fingerprint, key permissions, and local network in that order. See the connection guide for complete commands and troubleshooting paths.
View SSH troubleshooting stepsThe remote device should not be the only copy of your code, models, logs, or build artifacts. Assign actions for task start, execution, handoff, and completion.
List the code, dependencies, certificates, models, and test data that will enter the device. Confirm what must be encrypted and what must not be uploaded.
Store source files, caches, logs, and final artifacts separately so temporary credentials or unrelated debugging information are not exported along with them.
Download the required artifacts, verify file integrity, and confirm elsewhere that the backup can be read. A successful upload alone does not complete the handoff.
Delete credentials, private repository copies, model files, and temporary logs according to team policy. Revoke related tokens and record the cleanup result.
Review how site access, support communications, order-related information, and rental-device data are handled.
View the privacy policyReview the applicable rules for orders, account credentials, data backups, acceptable use, and dispute handling.
View the terms of servicePrice confirmation, gateway selection, and order payment take place during checkout. All charges are settled in USD, with only the following two payment methods supported; the console determines which gateway is available.
Complete payment using the amount and recipient details shown at checkout. Verify the network and order before submitting.
Card payments are processed by Stripe. The marketing site does not store complete card credentials directly.
Your report should help the support team reproduce the issue and determine its impact, while avoiding public disclosure of details that could still be exploited directly.
State whether the issue involves an account, order, node, connection entry point, or a specific device function.
List the prerequisites, steps, expected result, and actual result.
Provide the discovery time, the most recent known-good time, and the actions already taken.
Attach the necessary logs or screenshots, redacting keys, tokens, passwords, and complete payment details.
Provide the information needed to identify the order, but do not send credentials that could log directly into the device.
Check the workload, memory, storage, node, and rental term first. Then prepare individual credentials, a backup location, and a handoff owner for your team.