tenantplaneBook a demo To deploy a model inside your VPC, establish where inference and its dependencies run, install a compatible runtime, connect the application caller, and test the complete path. Downloading the weights is one step. The useful result is an application that can use the model within your approved boundary.
This is a scoping guide, not a tested cloud recipe or a claim of support for every model and cloud. Use a workload-specific implementation plan before changing your environment.
1. Name the requirement
“In our cloud” should identify an account, network, environment owner, and the data that must remain there. Include inputs, retrieved context, model responses, logs, and support exports.
| Requirement | Scope to examine | Unresolved question |
|---|---|---|
| Private network access | Private connectivity to a hosted service | Is processing in another account acceptable? |
| Model runs in your account | Model server and approved application access | Which other application services remain elsewhere? |
| Complete private application path | Caller, retrieval, storage, inference, and logging | Which components must move or change? |
| No external runtime dependencies | Runtime, identity, model artifacts, and support paths | How will installation, updates, and recovery work? |
A private network connection is not the same as model execution in your account. For example, AWS PrivateLink connects a VPC to a service endpoint; it does not itself move the provider’s service into your account. AWS PrivateLink concepts.
2. Choose one caller path
Identify the application action that needs inference. Write down the accepted input, expected output, authentication, timeout, and what the caller does when the service is unavailable.
For a synchronous scope, one request receives its response in the same call. A list of inputs in a request is not a durable job system. If your workload needs job IDs, persisted results, cancellation, or resumable retries, define a separate workflow contract.
Be explicit about what will be integrated. “One HTTP example” and “one existing application calling the service” are different deliverables.
3. Inventory the dependencies
Record each dependency’s destination, purpose, data transmitted, access timing, and owner. Include model acquisition, container and package registries, preprocessing, identity, telemetry, and external fallback services.
Separate installation from routine operation. An approved model download during setup is not permission for unrestricted runtime egress. Identify how each dependency fails, including whether failure could send data to an unapproved service.
Model hashes establish artifact identity. They do not prove that model behavior or dependencies are safe.
4. Qualify the installation
Record the exact model revision, license, runtime, operating system, accelerator, driver, memory, storage, and workload. Install from versioned files with secrets referenced through the approved mechanism rather than embedded in the package.
Agree on who provides private ingress, certificates, identity, logs, and network controls. Assign privileges separately for installation and runtime. For Kubernetes environments, review the official guidance on least privilege and escalation risks before approving roles. Kubernetes RBAC good practices.
An isolated network does not decide which user can access a document or invoke a tool. If those application permissions are within your scope, include them in the test plan rather than assuming the infrastructure supplies them.
5. Test the workload through the application
Define pass and fail before installation. At minimum, agree on:
- A successful request from the actual caller.
- Rejection of unauthorized, invalid, and oversized requests.
- Caller behavior when inference times out or fails.
- Resource and response targets for representative inputs and concurrency.
- The permitted network and logging behavior during normal use and failures.
- Restart and a failed-update recovery exercise.
- An operator following the handover procedure.
Retain actual conditions, raw results, failed checks, and exceptions. A model loading successfully is not a capacity benchmark. A synthetic lab reference is not acceptance of your installation.
Use the deployment acceptance template to record the release, caller, thresholds, evidence, and review decision. It is unfilled; none of its checks is represented as passed.
6. Agree on updates and operation
Name owners for access, capacity, patches, application changes, model updates, monitoring, backups where needed, and incidents. Describe support hours and approvals instead of using “managed” without a service boundary.
Tenantplane’s private workflow implementation connects one synchronous application path and hands over the release. The $7,500 starter provides the inference endpoint and one client example. Infrastructure and ongoing operation are separate costs.
For hardware-based installations, use the on-premises checklist. For cost comparisons, start with the worked deployment budget. Discuss your deployment with the blocker, environment, and timing.