Can a Base44 app store health data?
Not without asking first. Section 4.3 of Base44’s terms of service (June 22, 2026 version) has you commit not to upload data protected by specific legislation, with protected health information as the example, unless Base44 has agreed in writing beforehand.
The example is US wording (HIPAA), but the safe reading is that it covers health data under GDPR and UK GDPR too. If you’re in the US: Base44’s privacy page doesn’t mention HIPAA or a BAA. And its SOC 2 and ISO 27001 certifications don’t change any of this. They say the platform is well secured, not that any kind of data is allowed in it.
On your own servers, this clause stops applying to you: health data never reaches Base44, which only sees the app’s design and test data.
Does your app hold health data without you noticing?
Health data is anything that says something about a person’s health. Internal apps built outside IT pick it up without anyone meaning to, usually through fields designed for something else:
| Field or screen | Health data? | How to avoid it |
|---|---|---|
| Absence reason “sick leave” | Yes: it says the person is ill | “Authorised absence”, no reason. The fit note stays in the HR system |
| Incident report with the injury | Yes | The app logs the incident; the injury lives only in the health and safety system |
| Occupational health outcome (“fit with restrictions”) | Yes, even without a diagnosis | Store only the date of the last assessment |
| Allergies or dietary needs for an event or canteen | Yes | Collect it outside the app, or delete it after the event |
| Workplace adjustments, disability, pregnancy | Yes | Keep it out of the app |
| Free-text “notes” and PDF attachments | Can be: they end up holding what nobody planned for | Check what people type there and limit attachments |
| Shifts, clock-ins, holidays | Not on their own | Nothing to change |
The one nobody sees coming is the attachment: someone uploads a fit note as a PDF. It goes to file storage, which stays in the US even with EU residency, and if the app uses AI to read or summarise it, the contents reach OpenAI or Anthropic.
When the app moves to your own servers, this field-by-field review is step one: whatever isn’t needed comes out, and what stays gets role-based permissions.
If your app has none of these fields, this guide isn’t for you. What you probably want is how to run a Base44 app on your own servers.
Is Base44’s EU data residency enough?
It helps, but it doesn’t settle it. Residency decides where records are stored, not where they pass through. Per Base44’s docs as of October 4, 2026:
- It needs the Enterprise plan (or Elite, for workspaces created before October 1, 2026).
- It only applies to apps created after April 16, 2026.
- Files, account details and billing stay in the US.
A team with a health data app raised exactly this in the Base44 community in September 2026: even if data is stored in the EU, requests are processed in the US. Before signing up, they were asking for a dedicated EU tenant or a private deployment.
And residency is an Enterprise feature, which isn’t on the pricing page: you go through sales, the price is custom, and as a new vendor it has to clear your company’s security and procurement review. In the real migration behind Keep44’s guides, signing Enterprise had to go through procurement, legal and IT, and took more than six months.
Whether health data passing through the US is acceptable is your DPO’s call. The table at the top is what they need to see to make it.
On your own servers there’s no residency to buy and no new vendor to approve: health data is stored and processed inside your network, and whoever built the app keeps changing it in Base44 through the hybrid model.
Four ways forward
| Option | When it fits | What it takes | What’s left open |
|---|---|---|---|
| Remove the health data | The data isn’t essential (a sick leave reason, a notes field) | Change the fields in Base44 and delete what’s already stored | Almost nothing |
| Base44 Enterprise with EU residency | Your DPO accepts data passing through the US, and approving a new vendor is realistic | Enterprise plan plus Base44’s written agreement | Files, email and AI outside the EU |
| Own servers, hybrid model | The data is needed and can’t leave your network, or the app talks to internal systems | Migrate the backend; Base44 keeps test data only | Running the server. Health data never leaves your network |
| Rebuild it with IT’s tools | The app has become critical or is moving into clinical use | A full development project | The slowest and most expensive |
Keep44’s take: always start with the first one. Plenty of internal apps hold health data because of a text field nobody needed. If the app still needs it after the clean-up, pick from the other three.
What changes on your own servers
With the app on your servers, Base44 and every company in the table at the top drop out of production. In the hybrid model, whoever built the app keeps editing it in Base44, with test data only: what travels to your server is the design (screens, fields, logic), never real data. The mechanics are in how the hybrid model works.
What it solves: health data stays inside your network, no agreement with Base44 is needed, nobody trains AI on it, and files and email stay in-house.
What has to be done right in the migration, because Base44 used to handle it:
- Role-based permissions, rewritten and checked table by table: who sees sick leave, who sees incident reports.
- A log of who looks at that data.
- Encryption and backups under your own policy.
- AI: if the app uses it, switch to a provider your company has approved, or drop it.
In the real migration behind Keep44’s guides, that last point is what stopped IT: the risk of company data ending up training an AI model. The app used Base44’s built-in AI, and it had to come out during the migration. With that gone, so was the question, and the app went live without waiting for Enterprise.
Everything this guide says about Base44 was checked against its terms and docs on October 4, 2026. Not yet confirmed: on what terms Base44 agrees in writing to health data.
When Keep44 isn’t the answer
If the health data can come out of the app, take it out: it’s cheaper than any migration and you don’t need outside help. And if your DPO is fine with EU residency and Base44 signs the agreement, that works too.
It’s also not the answer if the app has turned into a clinical tool for patients. Then the sensible move is to rebuild it with IT or a healthcare vendor.
What IT needs to know
- What’s there: which tables and fields hold health data, including free text and attachments.
- Where it goes: with Base44, through US companies even with EU residency; on your own servers, nowhere.
- AI: which screens call the built-in AI, and with what data. Outside Enterprise, it may be used for training.
- Access: role-based permissions and a log of who views health data.
- Old data: whatever is already stored in Base44 has to be deleted. Deleted apps sit in the trash for 30 days.
- Who decides: IT owns the technical side; the DPO decides whether the processing is acceptable.
This guide covers the technical side. The legal call on health data belongs to your DPO.
Sources
- Base44: Terms of Service, section 4.3 (June 22, 2026 version). Checked Oct 4, 2026.
- Base44: list of companies that process data (Exhibit C of its data processing addendum). Checked Oct 4, 2026.
- Base44: Privacy and security (residency, AI training, trash). Checked Oct 4, 2026.