Academy

Why we run our own models on home infrastructure

Running models on our own infrastructure isn't just a technical choice; in an on-premise deployment, it means full control and isolation of your data. This is our decision and its reasoning.

The Felesh team 5 min

We could have taken the simplest route: call models from an external provider and consider it done. But we chose another path — we run our own models on home infrastructure. This isn’t just a technical choice; it is a conviction about what a trustworthy intelligent system should stand on.

One thing to make clear from the start: what follows applies to on-premise deployment, where the model and the data both stay inside the customer’s environment. In cloud deployments or showcase versions, external providers may still be used. This is not a blanket promise for every form of deployment — it is the option that puts control and isolation in the organisation’s hands.

Independence

The first reason is independence. When the core intelligence of a product is tied to an external provider, the product’s fate is tied to it too: its pricing, its availability, its decisions about what is and isn’t allowed. We believe a serious system shouldn’t be that dependent. Running our own models means the product’s path is in our own hands, not in the hands of someone whose decisions we can’t control.

Three provider decisions reach your productA provider raises the price per million tokens, retires the model early and blocks a topic. Each decision feeds the product box, whose path used to be yours and is now set by the provider. The last line: a change you did not choose lands in your product.what the provider decidespriceper 1M tokens: raisedavailabilitymodel retired earlyrulestopic now blockedyour productits pathset by providerthe change lands in your product; you did not choose it
Behind a provider's API, its price, its retirements and its rules reach your product without your vote.

Keeping data at home

The second reason is data. When data is sent to an external service for processing, it leaves your boundary of control. For many uses — especially those dealing with sensitive information — this is simply not acceptable. Running models on home infrastructure means data stays home: under the roof where it should be, without having to go somewhere it shouldn’t for processing.

One payroll row, two routes to a modelPayroll row 0417 reaches a model two ways. In a cloud API call the row leaves your system and crosses your boundary to the provider’s servers, and a break mark sits on that crossing. On-premise, the model runs on your own hardware in your server room, the row never leaves the room, and the model and the data both stay under your roof.cloud APIyour boundaryyour systempayroll row 0417providerservers, not yoursrow leaves your boundaryon-premiseyour server roompayroll rowmodel, in-housethe model and the data both stay under your roof
A cloud call takes the payroll row across your boundary; on-premise, the model goes to the row and the row stays home.

Local language and context

The third reason is local fit. Models cultivated for the Persian language and context perform better in our users’ real work. Building the ability to run these models on our own infrastructure lets us invest in exactly what matters most to our users, rather than settling for what a general provider offers.

A conviction, not a claim about numbers

We want to be honest: this is a strategic decision, not a claim about numbers. We’re not saying this route is always cheaper or faster; we’re saying we value independence, keeping data at home, and long-term durability, and we’re willing to pay for it. This is a choice based on priorities, and we state those priorities clearly.

The alternatives, and where ours loses

Ours is not the only defensible choice, and it isn’t the right one for everyone. The honest field looks like this: a cloud-API-only setup is the fastest to stand up and offloads all the operational burden, at the price of sending data across your boundary and tying your fate to a provider. Multi-tenant SaaS is cheaper and simpler still, but your data shares a platform with everyone else’s. A fully air-gapped deployment maximises isolation but gives up the convenience of any managed service and slows every update to a manual crawl. An ecosystem-locked stack is smooth as long as you stay inside one vendor’s walls — and costly to leave. Our position — on-premise by default, plus an isolated, Felesh-managed cloud — sits deliberately toward the control end of that spectrum.

Five ways to run a model, and what each gives upFive options, each with what it gains and what it gives up. Cloud API: fastest to start, but data leaves your boundary. Multi-tenant SaaS: cheapest and simplest, but data shares a platform. Air-gapped: maximum isolation, but every update is manual. Ecosystem-locked: smooth inside one vendor, but costly to leave. Ours, on-premise with an isolated Felesh-managed cloud: control and isolation, with up-front cost, operations and late access to new models.optionyou gainyou give upCloud APIfastest to startdata leaves your boundaryMulti-tenantcheap, simpledata shares a platformAir-gappedmax isolationevery update is manualVendor-lockedsmooth, one stackcostly to leaveon-premisefull controlup-front, late models
Each option buys something and charges for it; ours buys control and isolation, and the bill is up-front cost and slower access to new models.

And it loses something real to get there. Running your own infrastructure costs more up front than a metered API and carries an ongoing operational burden — hardware, serving, upgrades — that a cloud provider would otherwise absorb. It is slower to spin up, and slower to adopt the newest frontier model the day it ships, because we have to bring it in-house rather than flip a flag. For a small team, a low-sensitivity workload, or a quick experiment, a cloud API is very often the better trade. We choose the control end because durability and isolation matter most for the systems we build — not because the other options are wrong.

A cloud model switches on in one step; on-premise runs in sequenceOn the day a new model ships, the cloud track switches on in one step: flip the flag, same day. The on-premise track runs in sequence: bring the model in, check it, then serve it to users. The gap at the end of the on-premise track is the price of control: the model arrives later, and it is yours.the day a new model shipsday zerocloud APIon-premiseflip a flag, same daybring it incheck itserve itthe gap is the price of control: later, and yours
Switching on a cloud model is one flag; bringing the newest model in-house is a sequence, so it arrives later.

Putting it together

Running our own models on home infrastructure is a long-term entrenchment: independence from others’ decisions, keeping data under our own control, and investing in local fit. We believe an intelligent system meant to stay trustworthy for years should stand on a foundation it controls itself. This is our decision, and this is its reasoning.