On-premise
Software deployed inside the customer’s own network — close to self-hosting, but not the same thing.
TL;DR
Software deployed inside customer network.
Quick facts
- Category
- AI & knowledge management
- Product tie-in
- KobiGPT RAG platform
- Related
- See compare and tools pages
- Locale
- TR and EN site
Why teams choose KobiGPT
- Understand terms before evaluating vendors.
- Link concepts to KobiGPT features (RAG, Kobi Kredi).
- Share glossary links with procurement and legal.
- Explore assistant use cases next.
Product facts
- Ücretsiz plan
- 100 doküman · 2 departman · 120 Kobi/ay(PLAN_CONFIG)
- Starter
- 1000 doküman · 5 departman · 1000 Kobi/ay(PLAN_CONFIG)
- Pro
- 12500 doküman · 25 departman · 12500 Kobi/ay(PLAN_CONFIG)
On-premise versus self-hosted
The two terms are often confused. Self-hosted means the software runs on infrastructure under your control, which may well be servers you rent from a cloud provider.
On-premise is narrower: the software runs physically inside the organisation’s own network, on its own hardware. External network access may be restricted or absent entirely.
The distinction matters in practice because the requirements differ. Self-hosting is usually sufficient for data residency; on-premise typically arises from a network isolation requirement.
Constraints that network isolation brings
In a deployment without external network access, model calls become a problem. A cloud-based language model cannot be used; either a model running inside the organisation is required, or a controlled egress path must be defined.
The same constraint applies to embedding. In KobiGPT, embedding can run without external dependency by hosting the same multilingual model in your own infrastructure.
These constraints do not change product behaviour, but they raise deployment complexity considerably and demand serious capacity planning on the infrastructure side.
Making the decision
An on-premise decision is right when network isolation is genuinely mandatory. If a contract or regulation forbids external network access, there is no alternative.
If the requirement is only data residency, a self-hosted deployment usually provides the same protection at far lower operating cost. Treating the two options as equivalent creates unnecessary expense.
Ask the model access question early in any evaluation: where will you call the model from? That single question often determines on-premise feasibility from the outset.
Applying On-premise versus self-hosted in a controlled workflow
A useful way to evaluate on-premise is to follow one real question from the source document to the final answer. Record which file was selected, what context reached the model, and what a reviewer would need to verify. This turns a definition into an operational check and makes the result comparable across teams.
The same check should include ownership and change management. Decide who updates the relevant documents, how an outdated result is reported, and which access boundary applies. KobiGPT can provide the assistant and the cited document context, but the organisation still owns the source material, permissions, and the decision made from the answer.
FAQ
What is On-premise in practice?
Software deployed inside customer network.
Does KobiGPT use this?
See product docs and feature pages for implementation details.
More reading?
Visit our blog and FAQ.
Accuracy disclaimer?
Educational content; verify for compliance decisions.
Are on-premise and self-hosted the same?
No. Self-hosted covers any infrastructure under your control; on-premise means the organisation’s own network and hardware.
How does the model work without external access?
A model running inside the organisation is required, or a controlled egress path must be defined; embedding can run in your own infrastructure.
Comparison
| Feature | KobiGPT | Alternative |
|---|---|---|
| SME focus | Yes | N/A |
| Citations | When using RAG | N/A |
| Glossary depth | Growing | N/A |
| Tools | Interactive | N/A |