On-Premise Test Management: What the Requirement Actually Means Now

A security review flags "must be on-premise" as a requirement for the new on-premise test management tool, and whoever owns the selection has to figure out what that actually means before they can shortlist anything. It rarely means what it meant a decade ago, when the only option was a server humming in a closet down the hall. Get the translation wrong and you either reject a tool that would have satisfied the reviewer, or you commit to running hardware nobody on the team wants to maintain. This post translates the enterprise vocabulary into the deployment reality, so you can work out what actually satisfies the requirement sitting in front of you.

The vocabulary problem

On-premise, self-hosted, private cloud and single-tenant get used interchangeably by buyers and vendors, and they do not mean the same thing.

• On-premise, in its original sense, means hardware physically in a building your company controls
• Self-hosted means you run the software, but it can be on a cloud VM you rent from Amazon or Google, nowhere near a building you own
• Private cloud usually means dedicated infrastructure, sometimes vendor managed, that is not shared with other customers
• Single-tenant means your data lives in its own database or instance, separate from every other customer's, regardless of who operates the servers

A vendor's sales page might call a single-tenant cloud offering "private on-premise deployment," which is a contradiction if you take the words literally. Buyers use "on-premise" as shorthand for a bundle of concerns, not as a literal description of a building, and that gap is where mismatched expectations start.

This plays out in real procurement conversations. A head of quality at a 200 person software company once told her security team the test management tool would be "on-premise," then discovered during the actual review that she meant a Docker container in the company's own AWS account. The security reviewer, working from a checklist written for physical servers, flagged it as noncompliant until someone walked through what the checklist item was actually protecting against.

What the requirement usually means once you ask

Ask the person who wrote "must be on-premise" what specifically they need, and the answer is rarely about a building. It is usually three things bundled together.

The data has to sit in infrastructure your company controls, under your own access policy, with no vendor employee able to read it. A procurement team that inherited this requirement from a compliance framework is protecting against a specific risk: a vendor support engineer browsing customer data without anyone on your side knowing.

That risk exists whether the server is in your closet or in a cloud account with your name on the billing statement. A container running in your own AWS account, with your own IAM policy controlling who can access it, satisfies the same underlying concern as a physical server in your building. The building was never the point. Control over access was.

The four deployment shapes, ranked by control

Once you separate the requirement from the vocabulary, four real deployment shapes cover almost every option a vendor offers.

• Vendor multi-tenant cloud: everyone's data lives in shared infrastructure the vendor operates, with logical separation between customers
• Vendor single-tenant cloud: your instance is isolated, but the vendor still operates the infrastructure and can technically access it
• Self-hosted in your own cloud account: you deploy the vendor's software into infrastructure you control, and the vendor never touches your running instance
• Hardware in your own building: the traditional on-premise setup, with your team owning the physical machines too

Control increases as you move down that list, and so does the operational burden your team takes on. A vendor multi-tenant cloud gives you almost no infrastructure work and the least control.

Hardware in your building gives you full control and the most work. Patching, backups, capacity planning, and physical security are now entirely yours, on top of everything the tool itself already asks of your team.

What each shape actually costs in operational work

Self-hosted in your own cloud account is the shape most teams land on once they price the alternative honestly. You get most of the control a physical server would give you, without owning hardware, racking it, or replacing a failed disk at 11pm.

What it does cost: someone has to apply security patches, someone has to size the instance correctly as usage grows, and someone has to own the upgrade cadence so the tool does not fall three major versions behind. That is real, recurring work, typically a few hours a month once the initial setup is done, not a one time cost.

Hardware in your own building adds physical security, power redundancy, and hardware replacement on top of everything self-hosting already requires. Consider the team that self-hosts on a single cloud VM today at roughly 40 dollars a month in infrastructure cost, plus a couple of hours a month of maintenance. Moving that same setup into owned hardware would add a server purchase, a UPS, and someone on call for hardware failures, for a control benefit that a locked down cloud account already delivers.

For most software teams evaluating a test management tool, that additional cost buys nothing the cloud account version did not already deliver, unless a specific regulation names physical location.

The question that actually decides it

Once the operational costs are on the table, one question separates a real requirement from a preference: is the driver a contract, a regulator, or a habit.

A contract clause naming a specific hosting arrangement is non-negotiable. If a customer's master service agreement specifies data must remain in infrastructure the buyer directly controls, that is not up for debate, and self-hosted or physical on-premise are the only shapes that satisfy it.

A regulatory requirement works the same way. If a specific regulation in your industry names a control that only a self-hosted or physical deployment satisfies, that settles the question too.

A preference is different. "We've always run things on-premise" or "on-premise feels safer" are real feelings, but they are not contractual or regulatory constraints. Those deserve to be weighed against the operational cost of self-hosting, not treated as automatically decisive.

A team that has never staffed an on-call rotation for infrastructure should think hard before taking that on for a preference rather than a requirement. The honest version of that conversation, held once at the start of a tool review, saves months of second guessing later.

Our guide to test case management basics covers the broader tradeoffs worth weighing once deployment shape is settled.

Multi-tenancy as a paid tier is a real pattern here

Deployment shape is not always bundled into every plan a vendor sells. Single-tenant or self-hosted options are frequently gated behind higher priced tiers, and that is worth pricing in before you commit to a shortlist.

Kiwi TCMS places multi-tenancy in its Enterprise tier, at 600 dollars a month (kiwitcms.org features page, checked 25 August 2026). That is a disclosed, public price point for one vendor in this category, not a universal rule, but it illustrates the pattern: the deployment shape you need may not be the one your first quote assumes.

A team that budgeted for a 50 dollar a month starter plan, assuming self-hosting was included everywhere, can find the real number is closer to 600 dollars once the actual requirement is on the table. Worth asking any vendor directly and early: which of the four shapes above does each pricing tier actually deliver, and does the price change if the requirement is a contract clause rather than a preference.