Route multi-tenant agent workloads with Polyaxon
Route multi-tenant agent workloads through Polyaxon projects, queues, scoped connections, and explicit Kubernetes isolation and capacity policies.
A multi-tenant agent product must prevent one customer's execution from affecting another customer's data or capacity. That requires more than attaching a tenant label to a shared workspace.
Polyaxon can organize workloads through projects, access controls, and commercial scheduling capabilities. Your application and Kubernetes deployment must turn those primitives into an enforced tenant design.
Resolve tenancy in trusted application code
Authenticate the request and map the tenant to an approved execution profile. Resolve the Polyaxon project, queue, connections, and workspace ownership on the server side.
Do not let a model-supplied argument select another tenant's project or run UUID. The same ownership check applies when retrieving status, reconnecting to a sandbox, or downloading a report.
A project is useful for organizing access and evidence, but an application tenant is not automatically a Polyaxon project. Choose the mapping deliberately and document any shared infrastructure.
Choose placement by the required boundary
| Requirement | Possible design element |
|---|---|
| Separate user access to run records | Project permissions and application authorization |
| Limit noisy-neighbor capacity | Queue concurrency and quotas where available |
| Separate workload networking | Namespace design and network policy |
| Stronger infrastructure separation | Dedicated compute pools or clusters as required |
| Separate data access | Tenant-scoped external credentials and storage paths |
Polyaxon queues can route operations to configured compute agents and restrict available queues for projects. These are commercial capabilities; check the deployment's edition and configuration.
A compute agent manages a namespace or cluster. Routing to one does not automatically supply a separate hardware boundary or tenant-specific egress policy.
Keep workspaces and credentials tenant-scoped
Use a fresh or explicitly assigned sandbox service for the session. Never share a writable directory across unrelated tenants without a storage design that enforces the intended access boundary.
Attach only the connections needed for that workload. A common database connection with unrestricted credentials can defeat otherwise careful compute separation.
Keep reusable images separate from mutable tenant state. An image cache may be shared operationally; private documents and generated patches should not be.
Apply budgets at more than one level
Bound command duration, output size, session lifetime, and application request rate. Then configure queue concurrency or quotas to protect shared capacity where those controls are available.
Account for fan-out. One user request that creates many child tasks can consume far more resources than one ordinary job. The controller should apply a cumulative request budget, not only a per-command timeout.
Track waiting time and failures by approved tenant identifiers without exposing private content. A persistent imbalance may require a different resource profile or placement strategy.
Prove the boundary with controlled cases
Use synthetic tenants to verify denied cross-session access, separate outputs, correct credential placement, and cleanup before reassignment. Include a deliberately resource-heavy task to observe its effect on neighboring work.
Record the configuration and results with Polyaxon tracking. Retain evidence for the deployment version actually evaluated.
Multi-tenancy is a property of the complete system. Polyaxon contributes organization, scheduling, and run visibility; the application and infrastructure enforce how customers share—or do not share—the underlying resources.