Separate each session's files and processes. Set limits on shared resources and control access to the runtime. Keep decisions about business permissions in the application that owns them.
Each VM session has separate files and processes for its work.
Set resource quotas on the host so workloads can share capacity.
Host-level tenant ownership scopes access. Your application handles user and business permissions.
With VMYard's VM backends, each session has a separate Linux guest, files, and processes. An agent can use its own tools and working directory without sharing the same guest environment with other sessions.
Your team chooses the guest image and the permissions around the workload. Evaluate untrusted code and sensitive data against your security requirements; isolation is one part of that decision.
A busy workload should have a defined resource budget. Set host-level limits for CPU, memory, disk, session count, and concurrent requests. Assign session ownership so tenants can operate their own workspaces.
These controls make allocation explicit. Saved sessions still consume disk, and a returning session needs room within both the host's capacity and its tenant's budget.
Tenant ownership and quotas are enforced at the host. Administrators can access all tenants. Fleet clients have administrator-level access across the fleet, so the fleet interface belongs with trusted services. Your application must enforce end-user authorization before forwarding their requests.
Guest networking starts disabled. For workloads that need outside services, enable it with a destination allowlist and the host network controls your team operates.
Connectivity also affects where saved work can go: network-enabled sessions cannot move or replicate snapshots between hosts.
The destination allowlist applies to the runtime's guests on a host, not independently to each session. Different access requirements need separate host configurations or an application-controlled service. Your team configures and verifies the surrounding firewall and network access.
Provide a command with the named credentials it needs. VMYard injects them into that command's environment and removes exact matches from returned or streamed output.
Output redaction cannot prevent a command from transforming, saving, or transmitting a secret. Saved memory and guest disks may contain sensitive data. VMYard does not encrypt snapshots; your deployment must provide appropriate storage protection and credential handling.
Runtime access answers who can operate a session. Your application still decides whether an agent may send a message, modify a customer record, or approve a payment.
Optional certificate-based remote access lets trusted services authenticate to VMYard. Keep your product's login, approval rules, and record of actions connected to the business systems they govern.