Managed or Self-Hosted? How to Choose Hosting for a HIPAA-Compliant App

Introduction

Every healthcare app team reaches the same question before launch: who runs the servers that hold patient data, and where? It sounds like an infrastructure choice. In practice it decides how much of your team’s week goes to security operations, which customers you can sell to, and how painful it will be to change course later.

Whichever model you choose, the safeguards are the same, and any outside provider hosting ePHI for you must sign a BAA, as covered in what HIPAA-compliant hosting requires. What changes is who does the work. This post is about making that call for your app, at your stage, without boxing yourself in.

One distinction matters throughout. By self-hosted, we mean your team operates the infrastructure wherever it runs. Where it runs is a separate choice: a vendor can also manage an environment inside your own cloud account.

Four Questions That Decide Where Your App Runs

Start with these, in this order. The answers usually narrow the choice to one or two options before you compare a single vendor.

1. Must ePHI live in an account your organization controls?

Some buyers require it. Health systems, payers, and government programs often write data location and account ownership into their security reviews. If your target customers do, you need hosting in your own cloud account or on your own servers from the start, or a clear path to it. If they don’t, a vendor-run environment with a BAA is usually the faster route.

2. Who on your team will run security operations?

This is the question teams underestimate most. Self-managed infrastructure means someone owns patching, log review, restore tests, and incident response on an ongoing basis. If you can’t name that person, look at managed hosting.

3. How soon do you need to launch?

Managed hosting can shorten infrastructure setup because the environment, the BAA, and baseline controls already exist. Either way, application readiness and your customers’ security reviews still take time, so plan for them from the start.

4. What will your customers’ security reviews ask for?

Enterprise healthcare buyers send long questionnaires. They ask for independent audit reports, penetration test results, where data is stored, and who can access it. A managed provider can usually supply its share of that evidence. If you self-manage, you assemble your infrastructure provider’s evidence and document your own controls.

Managed or Self-Hosted: What Small Teams Should Know

For most early-stage healthcare teams, managed hosting can considerably reduce the infrastructure operations burden, because the work of running ePHI infrastructure never stops. Here is what self-managing adds to your team’s workload:

• Patching: operating system, database, and dependency updates are applied promptly when a security fix lands.
• Log review: checking who accessed patient data and investigating anything unusual.
• Backups and restore tests: proving, not assuming, that you can recover.
• Access reviews: removing leavers, checking admin rights, and rotating keys and secrets.
• Incident response: someone on call who knows what to do, including HIPAA breach-notification steps.
• Documentation: risk assessments and policies that describe what you actually run.

Each of these follows from HIPAA’s safeguards, and none goes away after launch. Self-managing can make sense when you already have a security or DevOps team, or when contracts require it. If you’re building on AWS yourself, our guide to setting up a HIPAA-compliant environment on AWS covers the configuration side.

In the deployments we support, a pattern we see is a small team that self-manages to save money, then spends more engineering time on operations than on the product. Managed hosting moves the agreed infrastructure tasks to people who do them full time. Your application’s access controls, vendor oversight, and compliance responsibilities stay with you.

Matching the Hosting Model to Your Requirements

There’s no fixed path from one model to the next, and an enterprise product can stay on vendor-managed cloud indefinitely. Let specific requirements decide instead:

• Limited operations capacity: consider vendor-managed hosting, shared or dedicated.
• A contractual isolation requirement: evaluate dedicated resources reserved for your organization.
• A customer requiring account ownership: consider deployment in your own cloud account, which your vendor can still manage.
• A requirement to operate in your own facilities: evaluate on-premises deployment and the staffing it needs.

When Your Communication Vendor Hosts the PHI

If your app uses a third-party chat, video, or AI service, ePHI may be processed or stored in that vendor’s environment, depending on the service and how it’s deployed. Messages, attachments, and call recordings can sit wherever the vendor runs, though some vendors support deployment in an environment you control.

Many communication vendors can only host in their own cloud account. That works with a signed BAA until a customer asks for that data in your account or in a specific region. Before you commit, ask each vendor:

• Can you deploy in our own cloud account if a customer requires it?
• Which regions can you host in?
• Can we export our data, including attachments and recordings, in a usable format?

Moving Between Models Without a Compliance Gap

If you change hosting models, the risk is a gap during the move, when data sits in two places under two sets of controls. Plan for:

• BAA coverage: BAAs are in place with any new provider handling ePHI before data moves.
• A complete data map: databases, file storage, recordings, backups, and logs are all accounted for.
• Testing and rollback: access controls, data completeness, and recovery are validated in the new environment before cutover, with a way back if something fails.
• Audit trail: access logs from the old environment are kept for your retention period, not lost at cutover.
• Old copies: data and backups left behind are retained or destroyed according to your documented retention policy and contracts, and the outcome is recorded.

Common Mistakes

Choosing on-premises “for security” without an operations team. Servers you own are only as secure as the people running them.

Putting real patient data in development and staging. Test environments rarely have production controls. Use synthetic or de-identified data.

Leaving vendor and support access unreviewed. Every person and service with access to production ePHI should be known, justified, and logged.

Choosing a vendor that can’t move with you. Teams often discover at their first enterprise deal that their communication provider can’t host in the customer’s preferred account or region.

Treating hosting as the whole of compliance. Hosting is one layer. The app itself needs its own safeguards; our HIPAA compliance checklist for telehealth apps covers the build side.

How QuickBlox Handles Hosting for Healthcare Apps

QuickBlox hosts the communication layer of healthcare apps: chat, video, file sharing, and AI agents. We built our hosting so teams don’t have to re-platform as they grow:

• HIPAA shared cloud: a managed environment with a signed BAA for pilots and early-stage products.
• Enterprise: a dedicated environment we manage with an SLA, in our cloud or in your own AWS, Azure or Google Cloud account.
• On-premises: deployment on your own servers when policy requires it.

Because the same platform runs in each, moving from shared cloud to your own account is a migration, not a rebuild. See the options for HIPAA app hosting, or talk to our team about where your app should run.

The hosting model is a staffing decision as much as a technical one. Start with where ePHI must live and who will run it day to day, choose for your current requirements, and pick vendors that can move with you when your first enterprise customer asks for something different.