Each VMCache rental provides one dedicated physical node with no processor, unified memory, or local storage shared with other tenants. Hardware isolation is foundational, but it does not replace account management, credential protection, backups, or service access controls.
These items are independent. Passing one does not mean the others are automatically satisfied.
A dedicated physical node reduces interference from shared compute resources, but service security still depends on how your team assigns accounts, stores secrets, exposes network services, and retains data copies.
Your order provides a dedicated physical machine. Its processor, unified memory, and local storage are not shared with other tenants, and it is not a shared virtual machine instance.
Connection data only establishes who can access the node. What they can do afterward is determined by system accounts, directory permissions, task identities, and internal team authorization.
The node's local disk is a runtime workspace, not a sole copy. Code, models, artifacts, logs, and configuration should enter your team's existing version-control, artifact, or backup workflows.
Read connection data only through the order management process. Do not copy it into public chat channels, ticket titles, code repositories, build output, or team documents without access controls.
First verify the order ID, model, node, and current delivery status to avoid putting another machine's connection data into the activity record.
Access the console through a trusted network and managed local device; do not display complete connection data during screen sharing, recording, or livestreams.
If your team must hand off access, use your own secrets manager and limit the objects, validity period, and audit scope.
Keep field names, failure stages, and necessary context; remove passwords, private keys, tokens, complete connection strings, and personal data.
Interactive login, CI/CD, and model services face different risks. Separate identities, directory permissions, and secret access scopes reduce the impact of mistakes or credential leaks.
| Identity Purpose | Recommended Permissions | Secret Scope | Logging Requirements |
|---|---|---|---|
| Interactive Login Manual configuration and troubleshooting |
Grant only the system and directory permissions needed for the current maintenance task | Do not retain automation tokens long term | Record change time, target, and result |
| CI/CD Dependency retrieval, builds, and archiving |
Limit the working, build-tool, and artifact directories | Read only the signing materials and repository tokens required by the pipeline | Retain the task ID in logs; filter environment variables and signing content |
| Model Service Load models and process requests |
Limit model directories, service processes, and listening ports | Read only model-source, service-authentication, and necessary storage credentials | Do not log complete prompts, tokens, or sensitive response bodies |
Start new tasks with no extra permissions; add auditable authorization only when a clear need arises.
Recheck account, token, directory, and network permissions whenever personnel, pipelines, or model services change.
Each task identity should be independently disableable without deleting the entire node or interrupting other workloads.
The node is suitable for builds and inference, but it should not be the sole location for code, models, or artifacts. Define the exit path in the deployment plan early so you do not discover missing recoverable copies when the rental ends.
First remove unrelated archives, old credentials, production-data copies, and personal information. Content that dependency tools can retrieve again does not need to be bundled into a long-lived image.
Organize directories by project or task batch. Store build caches, model files, output artifacts, and logs separately to simplify permissions, storage quotas, and cleanup rules.
Store source code in version control, build artifacts in an artifact workflow, and models and data in team-approved storage. Regularly verify that copies can actually be restored.
Export necessary artifacts, configuration, and redacted logs; verify file integrity and the destination. After confirming which data is no longer needed, run your team's own cleanup process.
Signing files, repository tokens, service keys, and environment variables should come from your team's own secrets workflow. Build scripts should reference variable names or controlled file paths, never store real values.
Store real values, limit readers, and retain change and revocation records.
Read only the minimum secret set required by the current pipeline while the task runs.
Output the task stage, exit status, and artifact location without echoing secret content.
Before launching an MLX inference endpoint, separately confirm process listening scope, access control, concurrency limits, log content, and model dependency sources. Validate on a restricted network first, then expand access.
Confirm the model format, loading process, unified-memory usage, and basic response.
Expose it only to test callers and verify authentication failures, timeouts, and malformed requests.
Increase requests gradually while monitoring memory, latency, error rate, and model-loading logs.
Record the final listening scope, caller identity, logging policy, and shutdown method.
| Check | Acceptable Result | Signal Requiring Adjustment |
|---|---|---|
| Listening Scope | Bound only to intended interfaces with a clear network access path | Listening on all interfaces by default with no identifiable caller source |
| Access Control | Caller identities can be revoked individually, and failed requests reveal no internal information | Shared long-lived tokens, or tokens written to clients and logs |
| Request Logs | Retain necessary time, status, and task identifiers with the body redacted | Full sensitive prompts, tokens, or model-input data recorded |
| Dependency Sources | Model and package sources are traceable, with clear versions and verification data | Runtime dependencies downloaded from unverifiable sources or with unknown versions |
If you find unusual access, misdirected credentials, unknown processes, or exposed services, first restrict the affected identities and services through your team process, then compile the order ID, timeline, impact scope, and redacted evidence.
Use only the external support email support@vmcache.com. Do not submit real secrets in the email body or attachments.
Confirm the model, node, and rental term first, then add accounts, secrets, backups, and interface checks to your team's own delivery checklist.