Where is the data, and who can use it?
It’s the first question and usually the one that decides. All of Base44’s servers are in the United States, and that’s where data is stored by default. On the plans with public pricing, its documentation says data can be used to train AI models.
In the real migration this guide is based on, that was IT’s fear: company data ending up in a model and surfacing in answers to third parties. OpenAI and Anthropic are among the subprocessors Base44 declares, so the question isn’t hypothetical.
EU residency exists, but only on Enterprise, only for apps created after April 16, 2026, and only for storage: requests may be processed in another region, and uploaded files, the account and billing stay in the United States.
On your own servers, data is stored and processed inside your network. The AI-training question disappears, because Base44 only ever sees test data.
Who can get in, and from where?
On the plans with public pricing, the app has its own user registry. It can offer “Sign in with Microsoft”, but that button isn’t company single sign-on: it doesn’t restrict access to your directory and doesn’t remove someone who leaves.
Single sign-on, automatic offboarding, the IP allowlist and audit logs are Enterprise features. Sign-in works over OIDC; the documentation doesn’t mention SAML, so if your identity provider only speaks SAML, ask before you negotiate.
One question no plan solves: if the app needs to read from SAP or an internal database, from the cloud it can only get there if that system is opened to the internet. In the Base44 community there are teams stuck right there, unable to go to production until they get a fixed IP or a VPN.
On your own servers, access plugs into what IT already uses, and the app doesn’t have to be visible from the internet. Internal systems are queried from inside, with nothing opened up.
Who has reviewed the app?
Usually, nobody from IT. Base44’s documentation is clear that each app’s security settings are the creator’s responsibility, and the creator is usually someone in the business who described what they wanted.
The usual failures are in permissions: a table any user can read in full, a role that can edit what it shouldn’t, a function reachable without signing in. Three checks IT can run in half an hour without reading code:
- Sign in as the lowest-privilege role and try to view and edit other people’s records.
- Open the app in a private window, signed out, and see what shows up.
- Ask the creator for each table’s access rules and the result of the platform’s security scan.
When the app moves to your servers, permissions are rewritten in the backend table by table, and it goes through the same review as any other company app.
What if it breaks or the vendor changes?
On Base44, backups belong to the platform: IT can’t roll an app’s data back to a point in time on its own. The code can live in a company GitHub repository (Builder plan or higher), and that’s the first thing to insist on.
The other question is who answers when something goes wrong. For an app built outside IT, the answer is usually “whoever made it”, with no backup person. Another user said in the same Reddit thread that their app wasn’t one that needed IT to get involved. Once a whole team depends on it, IT ends up answerable for something it has never seen.
Moving to your own server doesn’t fix this by itself. In the real migration, when IT asked who would maintain the app, there was no clear answer: one person had built and migrated it, and the plan was to lean on AI for whatever came up. It’s the question most worth settling before asking for approval.
On your own servers, data goes into your backups and code into your repository, with a named maintainer in writing. If the platform changes its plans or pricing, the app keeps running.
What Enterprise doesn’t solve
Enterprise answers several rows of the table: no AI training, single sign-on, automatic offboarding, IP allowlist and audit logs. But it isn’t on the pricing page: you ask for it through sales, and the price depends on the size of the workspace. As a new vendor, it also goes through security and procurement review. In the real migration, that request had been stalled for more than six months.
And once it’s signed, four things stay the same:
- Data is processed in Base44’s cloud, not just stored there, and uploaded files stay in the United States.
- The same third parties, AI providers included, stay in the chain.
- Internal systems stay out of reach unless you open them to the internet.
- IT still can’t restore the data or guarantee the app keeps working if the contract changes.
In the real migration, it was IT’s own lead who proposed the other route: moving the app to a company server. The tables were rebuilt in SQL Server, the app was served with IIS, and access was handled with a custom login with roles. How it’s done, piece by piece, is in the guide how to run a Base44 app on-premise, on your own servers.
When you don’t need it: if the app handles no personal or confidential data, or if the company already has Enterprise and its EU residency meets your policy, running the checks in this guide and approving it in the cloud is enough.
Checklist to copy
To paste into the email or the review ticket. Each point needs a written answer before approval.
- Vendor: whether a new one has to be approved, and how long that review takes.
- Data: region where it’s stored and where it’s processed, uploaded files included.
- AI: whether the plan lets the data be used to train models.
- Third parties: subprocessor list, signed data processing agreement and SOC 2 report.
- Access: which account people sign in with, and what happens to someone who leaves.
- Network: whether access can be limited to the internal network.
- Internal systems: which ones it needs to reach, and what would have to be opened.
- Logging: whether there’s a record of who views and changes what.
- Permissions: access rules for each table, tested with the lowest role and signed out.
- Code: a company repository holding a copy of the code.
- Recovery: who restores the data and how fast.
- Owner: who maintains the app, who covers for them, and what happens if the platform stops being paid for.
If you built the app: what to prepare before asking for approval
Arriving with this settled saves weeks of back and forth: the plan you’re on, a list of tables with the kind of data each holds, the access rules, the connected GitHub repository, and the name of whoever will maintain it when you’re not around.
Sources
- Base44: Privacy and security (data residency, AI training, server location). Accessed 10/4/2026.
- Base44: Security overview (creator responsibility, Enterprise features). Accessed 10/4/2026.
- Base44: Setting up SSO (required plan and OIDC providers). Accessed 10/4/2026.
- Base44: Enterprise (sales-led purchase, pricing by workspace size). Accessed 10/4/2026.
- Base44: Security you can build on (subprocessor list). Accessed 10/4/2026.
- Base44: GitHub Integration (code copy, Builder plan). Accessed 10/4/2026.