On-premise

The word was coined after its opposite arrived. Buying software used to mean installing it. A company kept a server room, the program went onto machines in that room, and since there was no other way to do it, the arrangement never needed a name.

That changed as renting through the cloud spread. Once products you simply log into became normal, companies needed one word for "we put it on our own machines," and on-premise filled the gap. The phrase is borrowed straight from the English for keeping something on the premises.

As a result the term comes up in contract negotiations far more than in product descriptions. The archetypal moment: a sales rep says the product is delivered through the cloud, and the security lead on the customer's side asks whether on-premise is an option. That single question pulls in product architecture, pricing, support headcount, and next quarter's roadmap all at once. It's also why the answer so often turns into a promise to look into it. A team that has never shipped an installer cannot say yes in the room, and saying no costs a deal that took months to reach.

It addresses situations where the customer's data cannot leave the customer's control. That condition is rarely a preference — it's usually written into a regulation or a security checklist, which means a product that can't meet it never gets as far as a contract. Three versions of the problem come up.

1. The network is cut off. Organizations at high security grades keep work machines off the public internet entirely. Nothing you log into can be used there. It isn't a matter of which product is better; the screen simply never loads.
2. Regulation pins the data down. Financial, public sector, and healthcare rules include clauses that forbid keeping certain categories of records on an outside vendor's servers. Even a buyer who wants to approve it gets stopped at audit.
3. Review takes months. Enterprise customers run a security assessment before admitting any outside service, asking for certification packets like SOC 2 and working down a list of encryption methods and access controls. Installing on the customer's own servers removes a large part of that process.

The reason vendors find these requests hard to refuse is the money. Customers who attach these conditions tend to be large, and a single contract lands somewhere around $150,000. One of them can matter more to revenue than tens of thousands of free-plan users.

The cost arrives later. A hundred installed customers means a hundred separate environments, installed at different times and drifting onto different versions. A fix that reaches everyone at once on a hosted product turns into a hundred scheduled upgrade visits. And when something breaks it's on somebody else's server, so nobody on the vendor's side can open the logs — the cause gets found over a phone call with an administrator describing what's on their screen. Every one of those calls also has to be scheduled against the customer's change windows, so a fix that takes an hour to write can take three weeks to reach the machine that needs it.

The usual move is to offer a middle step rather than granting or refusing the whole request. What the customer wants is often not installation itself but the guarantee that their data isn't mixed with anyone else's, and meeting that narrower condition unblocks the conversation. The sequence generally goes like this.

1. Open up single-tenancy. Each customer gets a separate server and database while the vendor keeps operating it. The requirement that their records not share a store with anyone else's is satisfied here, and because operations never transfer, versions don't drift apart.
2. Deploy into a region or account the customer names. The environment gets created inside the customer's own cloud account. It reads much like an installation, in that the data stays under their control, but updates can still be handled remotely.
3. If neither works, accept the request with terms attached. Set a contract minimum and a duration, write the support scope and upgrade cadence into the agreement, and fix how many versions will be supported at once. A first on-premise customer signed without those three written down is what typically destabilizes the roadmap for years afterward.

A company that has been running a single shared system through multi-tenancy feels the shift in its org chart before its codebase. Installation and upgrades need dedicated people, and those people spend their time tending customer servers instead of improving the product. That's the point where this differs from a request like white label, which only changes what the product looks like.

"This account won't sign unless we can do on-premise."

The deal is blocked by the delivery model, not by a missing feature.

"The three on-premise installs are all on different versions right now."

Version drift showed up as soon as installed customers accumulated.

"We can manage the install, but who goes out for the upgrades?"

Asking who carries the operational load for years afterward, not who closes the sale.

Pagedeck runs every customer on one shared system. Then Sofia brought in a public sector deal with a requirement that the product work on a network disconnected from the public internet, and the contract was worth a large share of that year's enterprise revenue.

When Grace, Theo and Sofia sat down, what they calculated was headcount rather than revenue: the people needed for the install and the upgrades after it, the features that would slip while those people were occupied, and what the situation would look like a few years in with three versions to maintain. They decided to propose single-tenancy first, and to accept an installation only with a three-year minimum and two scheduled upgrade visits a year if the air-gap requirement turned out to be immovable.

The most common belief is that keeping data on your own servers is safer. Records within reach feel safer, so the instinct is understandable. In practice security is decided by how something is maintained, not by where it sits. A cloud provider staffs a security team and patches continuously; the box in a customer's server room has often gone two years without an update because the administrator who owned it changed jobs. Trusting the location alone means passing a review while the patching schedule and access controls go unexamined.

The other one is treating installation as the end of the work. The agreement says delivery, which makes it sound like a one-time task. Installation is the start: security patches, feature updates, and problems that only reproduce in one customer's environment continue for the life of the contract. A first deal priced without that load becomes the weight that disrupts the team's schedule every quarter.