By Retvest · Updated 14 October 2026
Start with the deployment boundary
Deploying AI on your own servers means deciding where the application, model and information are processed, then assigning responsibility for operating them. For an organisation, the deployment also needs user access, approved knowledge, review and recovery. A useful starting point is a single workflow and a diagram of every place its information goes.
Self-hosted AI describes who operates the environment. On-premises AI describes where it runs. An organisation can operate its AI environment on its own hardware or in a cloud account it controls. Neither label, by itself, establishes that all connected models, tools and services stay inside the same boundary.
| Deployment choice | What your team operates | Decision to make |
|---|---|---|
| On premises | Application and model hosts on company hardware. | Who supplies capacity, storage, networking and recovery? |
| Company cloud | Application and model hosts in the organisation’s cloud account. | Which account, region, network and operating budget apply? |
| External model connection | The application can remain company-operated while model requests go to another service. | Which context leaves the environment, and under whose terms? |
The last row is a general deployment pattern, not a claim that every external provider is supported by Retvest. Agree the actual model connection and information policy for your installation.
Separate the application from the model
The application handles the employee workflow and its connection to company information. The model endpoint receives the task context and generates a response. Keeping these responsibilities distinct lets your infrastructure team choose whether both run on one host or the model needs a separate machine.
For a bounded pilot, a shared host may be simpler to operate when it has enough resources. A separate model host lets you size inference independently, but introduces another network route, credential boundary and service to maintain. Document how the application reaches it and who is responsible when it is unavailable.
Retvest’s documented company-server path uses a dedicated Linux Docker host, persistent storage and a company-operated model endpoint. Read the infrastructure requirements and model connection guide for the current configuration scope.
Follow one request through the architecture
Consider a pilot in which a small team asks questions about an approved policy collection. The employee signs in to the company application and submits a question. Access controls determine which material the workflow can use. Relevant context is sent to the configured model endpoint, and the resulting answer returns to the employee for review.
The information map should name the source collection, stored documents, retrieval index, model request, saved answer and retained activity. If the workflow also calls a web tool or external application, add that destination explicitly. Running the application locally does not prevent an authorised integration from communicating outside the environment.
In Retvest Deploy, RIL is the included system of record for supported, enrolled work. Agree which inputs, activity, review decisions and outputs belong in that record. Define who can access them and how long they are retained. A record supports review; it does not make the model’s answer correct.
Choose the model before sizing its hardware
Start with the task: document questions, longer research, code or a workflow that needs tools. Then establish the model capabilities, context length and expected simultaneous use. Memory needed to load a model is only one constraint; available context and concurrent requests also affect capacity.
Application requirements and model requirements are separate. An application host specification is not a GPU recommendation or a promise of response time. Keep a representative set of approved tasks for evaluating the chosen model and deployment before expanding access.
Retvest’s documented model connections include Ollama and an OpenAI-compatible endpoint. Protocol compatibility does not establish that every model supports every workflow. Record the selected model, served version and configuration with the installation handover.
Budget for running the environment
A deployment budget should account for the application host, model compute, persistent storage, backups and network services. It should also name the people responsible for updates, access changes, incidents and recovery. Add software licensing and any connected provider charges to the same plan.
Compare options using your expected workload and operating responsibilities. A server purchase alone is not the full cost of self-hosting. Retvest does not publish a universal savings percentage or capacity guarantee: the infrastructure and commercial scope are agreed for each pilot.
Write a pilot brief your team can use
A focused pilot gives the business and infrastructure owners a shared basis for deciding what to deploy. The following is an illustrative planning brief, not a customer deployment or a claim of measured results.
Download the editable deployment planning brief. Use the plain-text template with your business and infrastructure owners to record your own decisions.
| Planning area | Example decision |
|---|---|
| Workflow | Help an authorised team answer questions about an approved policy collection. |
| Information | Use a bounded sample collection with a named information owner. |
| Environment | Choose the application host, model endpoint and permitted network destinations. |
| Review | Agree expected answer quality, source review and behaviour when the information is insufficient. |
| Work record | Specify supported activity, review decisions, retained outputs and authorised readers. |
| Operations | Name the owners of credentials, upgrades, backups and recovery. |
| Expansion | Agree the evidence and approval required before adding users, information or integrations. |
Keep confidential material and credentials out of an initial enquiry. A high-level workflow description is enough to start the conversation; the approved environment and information handling can be agreed before sensitive material is introduced.
Where Retvest Deploy fits
Retvest Deploy brings company AI applications, knowledge and chosen models into one environment on infrastructure your organisation operates. Its scope includes Chat, Work and Code, agents and company controls. RIL, the Retvest Intelligence Layer, is included to connect supported work with its record.
Start with a walkthrough or pilot around your workflow, infrastructure and review requirements. Availability, integrations and operating responsibilities are agreed for that deployment. An on-premises installation does not by itself establish air-gap qualification, compliance or production readiness.
Explore Retvest Deploy or plan a deployment walkthrough. For a separate desktop assistant for individuals, see Sidekick by Retvest.