Managed cloud
Prajvis operates the environment. Models are configured for that cloud, and connections reach only the systems it can access.
Bring Prajvis into your environment. On your terms.
Managed cloud, infrastructure you operate, or an isolated environment. Bring your model providers, integrations, and access requirements with that choice.
Your agents
Build natively or bring your own
- 01Create
- 02Equip
- 03Run
- 04Review
- 05Repeat
Prajvis
Integrated runtime
- IdentityAccess and records
- ContextFiles and records
- ToolsMCP, APIs, integrations
- SandboxComputers and isolation
- ObservabilityRecords, activity, history
Deployment options
Your infrastructure, your rules
- CloudManaged by Prajvis
- Self-hostedYour VPC on AWS, Azure, GCP
- Air-gappedIn-network model endpoint
Run on our cloud. Or within your own.
Cloud when Prajvis should operate it. Self-hosted when the infrastructure is yours. Air-gapped when the environment cannot assume the public internet. The right choice follows network, model access, and how you operate, not a hosting preference alone.
Self-hosted
Your organization operates Prajvis on AWS, Azure, GCP, or a VPC you run. Network, access, and the model arrangement follow your policies.
Air-gapped
An isolated environment with no assumed public internet. Models stay in-network, and only systems inside that environment can be connected.
Agent execution uses hardware-level or tenant-level MicroVM isolation in each of these environments.
Bring the providers and systems you already use.
Provider choice stays with your organization, including arrangements already in use. An isolated environment uses in-network model access instead of an external endpoint.
Your model providers
Use a provider already in place, or the arrangement configured for that environment.
Your integrations
Integrations, APIs, MCP connections, and custom tools, as far as the environment can reach.
In-network models
Air-gapped operation depends on a model endpoint inside the environment.
No provider lock-in
The provider layer stays yours. Deployment does not fix you to one model vendor.
Define who can act. Keep the work accountable.
Identity, permissions, oversight, and review travel with the deployment you choose. Exact permission levels are confirmed for your organization, not assumed on this page.
- Identity provider
- People come in through the identity arrangement your organization already uses. How that connection is made is confirmed for the deployment.
- Who can act
- Choose who can create applications and agents, who can share them, and who can connect a system of record.
- Review
- Consequential follow-up stays available for a person before it proceeds.
- Action trail
- Supporting records, tool activity, and execution history stay with the work they belong to.
- Credentials stay separate
- Sharing an application or agent does not share credentials, private conversations, or every connected record.
- Where data is hosted
- Regional data residency can sit alongside the network the environment is allowed to use.
A private deployment is one part of the picture.
Isolation places the environment. It does not, by itself, set identity, sharing, or which records a person can see.
What it means
- The environment can run without assumed public-internet connectivity.
- Models and dependencies are configured inside it, with in-network model access.
- Only systems reachable inside the environment can be connected.
What it does not mean
- Public SaaS is unavailable unless that environment has the connectivity those services require.
- Externally hosted models are not assumed.
- Isolating the environment does not decide who inside it can create, share, or connect.
Make the fit clear before you roll it out.
Tell us the environment, the work, and the requirements that matter. We will stay inside what the product supports, and name anything that still needs to be validated.