Guide · Deployment
Cloud, Self-Hosted or On-Premise: Choosing a Deployment Model
Most hospital software comparisons stop at features. The deployment model is usually decided later, almost as an afterthought, and it is the decision that is hardest to reverse.
There are three models in practice, and the words used for them are not applied consistently. This is what each one actually means, what genuinely differs, and how to tell which one your hospital should be shopping for.
Written by the auraCare team · Last reviewed
Three models, described precisely.
The distinction that matters is not where the machine is. It is who controls the environment and who holds the database.
What actually differs.
Feature lists rarely differ much between deployment models of the same product. These are the properties that do.
| Vendor-hosted | Private cloud | On-premise | |
|---|---|---|---|
| Owns the infrastructure | Vendor | Hospital | Hospital |
| Holds the database credentials | Vendor | Hospital | Hospital |
| Chooses the hosting region | Vendor | Hospital | Hospital |
| Records pooled with other hospitals | Commonly | No | No |
| Day-to-day maintenance burden | Lowest | Moderate | Highest |
| Depends on internet connectivity | Yes | Usually | Can run on the LAN |
| Effort to leave the vendor | Highest | Lower | Lower |
| Incident at another hospital affects you | Possible | No | No |
| Cost shape | Operating, per period | Operating plus your cloud bill | Capital, then upkeep |
No row here is universally better. Which column suits you depends on what your hospital already runs and what it is obliged to control.
The trade-off nobody states plainly.
Vendor-hosted is genuinely easier. Somebody else patches the servers, monitors the database, handles the backups and gets paged at night. For a hospital with no IT staff and no appetite to acquire any, that is not a compromise — it is the correct answer, and a vendor who tells you otherwise is selling rather than advising.
What you exchange for it is leverage and locality. When the records live only in the vendor’s database, renegotiation is harder and leaving is a project. When the region is the vendor’s choice, a data-localisation obligation becomes their decision rather than yours.
Hospital-controlled deployment inverts both. You keep the leverage and you choose the region, and in return you take on an environment to look after. That burden is smaller than it is usually made to sound — a conventional application and a PostgreSQL database — but it is not zero, and pretending it is does hospitals no favours.
The third consideration is blast radius. On a shared platform, an incident affecting another hospital can become your incident, because you share infrastructure. Isolated deployments do not share that fate. Whether that matters depends on how much of your operation stops when the system does.
Which model suits which hospital.
In practice the choice is usually settled by three things: what infrastructure you already run, what you are obliged to control, and how much operational risk you want to carry yourself.
Choose vendor-hosted when
You have no IT team and do not want one, no regulatory requirement fixes where records sit, and you would rather pay for someone else to carry the operational risk. Ask what leaving looks like before you sign, not after.
Choose private cloud when
You already hold a cloud account, you need to decide the region yourself, or you want the records to remain yours if the commercial relationship ends. This is the middle path and, for most mid-sized hospitals, the practical one.
Choose on-premise when
Connectivity is unreliable enough that the hospital must keep working without it, or policy requires the hardware to be in the building. Budget honestly for the hardware refresh, the backups and the person who owns them.
Decide it early, either way
This is the hardest decision to reverse once records accumulate and staff depend on the system. It belongs in the first conversation with a vendor, alongside the feature list — not in the implementation phase.
What Indian hospitals should factor in.
The deployment model interacts directly with several Indian obligations, which is why it is worth settling before a contract rather than during one.
- Health data created in an Indian hospital sits under Indian requirements, including the DPDP Act 2023 and, for participants, the ABDM Health Data Management Policy. Choosing the region yourself is the simplest way to keep that question answerable.
- The CERT-In directions require certain logs to be maintained within Indian jurisdiction and set a six-hour window for reporting specified incidents. Whether you or the vendor is positioned to meet that depends on who holds the logs.
- Ask any vendor to state, in the agreement rather than in a sales conversation, which region the deployment runs in and who holds the database credentials.
- Ask what happens to the records at the end of the contract, and get the answer in writing. “We will export it for you” and “it is already yours” are materially different positions.
- Ask whether the vendor holds standing access to live patient data, or requests it per task. Both models exist; only one of them is easy to justify to a regulator.
Questions this usually raises.
Is self-hosted the same as on-premise?
No, and conflating them is the most common confusion here. Self-hosted describes who controls the environment and holds the credentials; on-premise describes where the hardware physically sits. A deployment in a cloud account the hospital owns is self-hosted but not on-premise. Most hospitals asking for “on-premise” actually want the control, not the server room.
Does hospital-controlled hosting mean we need our own IT department?
Not a large one. A deployment is a conventional application and a PostgreSQL database, and most hospitals either already run servers or hold a cloud account for something else. The vendor should handle installation and updates. What you hold is the environment and the data inside it — ownership, not day-to-day operations.
Which model is cheaper?
They are different shapes rather than different totals, and a comparison that ignores that is misleading. Vendor-hosted is an operating cost with the infrastructure folded in. Private cloud is a licence plus your own cloud bill. On-premise front-loads capital and then carries hardware refresh and staff time. Over five years the totals are often closer than the first-year quotes suggest.
Can we start on one model and move later?
Moving from hospital-controlled to vendor-hosted is usually straightforward. The other direction depends entirely on what your contract says about the data and what format you can get it in — which is why the exit terms matter more at signing than they will ever feel at the time.
Where auraCare sits in this.
auraCare is built for the second and third columns. Each hospital runs an isolated instance in an environment it chooses, against a database only it holds credentials for, and we keep no copy of the records. Support access is granted per task rather than held permanently, and it appears in the audit trail.
That is a deliberate narrowing, not a claim to suit everyone. If what your hospital wants is for somebody else to own the infrastructure and carry the operational risk entirely, a vendor-hosted product is a better fit, and you should buy one.
Where to check the regulatory points.
The obligations referred to above are summarised from primary sources. Anything a vendor tells you about them should be checkable against these.
- Digital Personal Data Protection Act, 2023 www.meity.gov.in The general data-protection statute governing personal data, including health data, in India.
- CERT-In www.cert-in.org.in Directions on incident reporting timelines and the retention of logs within Indian jurisdiction.
- ABDM Health Data Management Policy abdm.gov.in Consent, data minimisation and the obligations of a Health Information Provider or User.
- National Health Authority nha.gov.in The authority administering ABDM and granting participant registration.
Tell us what you already run.
The deployment conversation is far quicker with specifics: what infrastructure you have today, what your data-localisation obligations are, and who would hold the credentials.
We will tell you what a deployment in that environment looks like, including where auraCare would not be the right fit.
Hosting arrangements are written into the agreement before any patient data is processed.