Base44 on-premise: run your app inside your network

You built an app on Base44, your team uses it every day, and you want it running on your own servers, inside your company's network, behind your firewall. Sometimes on a network with no internet at all. I get requests like this every week: from a refinery's sysadmin, a car dealership in Germany, an HR team in Saudi Arabia. They all ask the same thing: how do I get my Base44 app onto our own server?

There's no version of Base44 you can install

Base44 has no installer, no Docker image, no self-hosted edition and no license to run it on your own premises or in your own data center. Every Base44 app runs on Base44's servers, next to everyone else's apps, and so do its database, its users, its logins and its files.

People have been asking Base44 for an on-prem version for over a year, on its feedback board and in its Discord. Nobody at Base44 has answered them, and on-prem is nowhere on its roadmap.

What the export, the Enterprise plan and a rebuild actually get you

With nothing to install, people try to get around it. None of the usual workarounds puts the app your team already uses inside your network:

1. Exporting the app and putting it on your server. It's the obvious first move, and it looks like it worked: the pages load from your IIS or your intranet server, and people can sign in. But only the screens moved. The app itself still runs on Base44's servers: signing people in, every record, the logic behind every button, the files, the AI, the emails, everything the app does goes over the internet to Base44, exactly as before. Cut your server off from the internet and the whole app stops working. Running it locally with Base44's own developer tools doesn't get you there either: that's a test copy with throwaway data, and it still can't run without Base44's servers.

   See exactly what Base44 export includes (and what it doesn't)

2. Upgrading to Base44's Business or Enterprise plan. These are the plans Base44 sells to companies. They come with company sign-in, an IP allowlist, data residency and audit logs, and it all sounds like the answer. It isn't.

   The IP allowlist only decides who can sign in, and Base44's own support staff can get past it. The data residency moves only your database to the EU or the UK, while the rest of the app keeps running on Base44's servers in the US. And you still can't touch your app's security.

   See why Base44's data residency doesn't actually change your app's regionSee why you can't control your app's security while it runs on Base44

   None of these plans gives you the one thing that matters: running the app inside your network. On every plan, Enterprise included, the whole app, everything it does and every record in it, runs on Base44's servers, and Base44 won't let it run anywhere else.

   What Base44's Business and Enterprise plans actually give you, item by item
3. Rebuilding the app to run on your own servers. This is what the agencies offer: SQL Server and IIS, or Postgres and Docker, a new login, and a backend written from scratch to replace Base44's. And it does work: at the end, something runs inside your network. But it's a full development project, months of work and a five-figure sum. And at the end you don't have your app. You have a new one, built to look like it: every screen, every permission rule and every function rewritten by someone reading the old ones, your users signing in with new accounts. Then your team tests it against the app they already use, flow by flow, to find out what came out different.

How an app normally runs inside a company's network

Inside a company's network, running an app is routine. It gets a server, usually a virtual machine on hardware the company already runs. On that server there's a web server, a database and a folder for files, and the app has its own login. People open an internal address, the server answers them from inside the building, and nothing leaves. Anyone working from home gets in over the company VPN. That's how the HR system, the ticketing tool and every other internal app already run.

The only reason a Base44 app can't run like that is that it has no backend of its own. On Base44, everything the app does runs on Base44's servers: signing people in, reading and saving every record, the permission rules, the logic behind every button, the files, the AI, the emails. The screens are the only part that runs anywhere else, and they call Base44 over the internet for all of it. Give the app a backend of its own, on its own server, and it's a normal app that runs wherever you put it: on a cloud account, on a server in the office, or on a network with no internet at all.

The problem is how to actually do that. On Base44, the backend belongs to Base44, not to your app, and Base44 doesn't give it to anyone.

How to run your Base44 app inside your network without rebuilding it

This is why I built EscapeBase44. I got stuck on Base44 with an app of my own, spent months reverse-engineering Base44's entire backend until my app could run without it, and then automated the whole thing. EscapeBase44 moves the app you built and gives it a backend of its own. Everything comes with it: every screen, every record, your users and their permissions, the uploaded files, the backend functions and the scheduled jobs. For a company network, I do the move for you, and the app arrives as one package, ready to install.

That's the whole difference from a rebuild. Nothing is rewritten, so there's nothing to test against the old app to see what came out different: it's the same app your team already uses. It's ready within a week instead of months, and it costs a fraction of what a rebuild does.

The package is a single file, and everything the app runs on is inside it: the web server, the backend, the database with your data already in it, the files and the scheduled jobs, each in its own Docker container. You copy it onto one Linux server inside your network and run one script. That's the whole install. The app goes live on an internal address that only people inside your network can reach, and nothing in it talks to Base44 anymore.

I never get access to your network. The runbook covers the whole install, and if whoever installs it has a question, I answer it myself. Your Base44 app keeps running, untouched, until your team moves over, and right before they do, you get a fresh package with the latest data in it.

You pay once, and only when your team is working in the app and nothing is missing. If anything behaves differently from Base44 in the first 30 days, I fix it for free.

The technical details:

• One Ubuntu VM with Docker: 2 CPUs, 4 GB of RAM and 40 GB of disk. On a Windows network, Hyper-V or VMware runs it.
• The web server (Caddy), the backend (Python) and the database (MongoDB) each run in their own container.
• One internal hostname, with HTTPS on your own certificate. Email goes out through your own mail relay.
• No internet needed to install the app or to run it. Updates come from your own repository, or as a file on a network with no internet.
• The database is dumped on the server every day, and the dump and the files go into your normal backups.
• The complete code, backend included, is in your own repository, so all of it can be reviewed before anything is installed.
• The move runs under an NDA, signed before work starts. Your data passes through my systems only while the package is built, and isn't kept.

Your users keep their accounts, their roles and their data. The first time each person signs in on the new server, they set a new password. Or they sign in with their work account, through Microsoft Entra ID or your own Active Directory, and whoever leaves the company loses access the day their account is turned off.

If the app uses AI, it runs on whatever your company approves: a provider with your own key, or a model running inside your network. And now that the app sits inside the network, it can reach your internal systems, like a SQL Server or an internal API, without anyone opening the firewall.

The code is yours now, backend included. It's a normal app, so you can change it any way you want, with any developer or with tools like Claude Code and Cursor. When a change is ready, the same script installs it on the server.

Once it's installed, it's an internal app like every other one in the building: on your server, behind your firewall, with no Base44 or EscapeBase44 in the picture anymore.

Base44 on-premise FAQ

• Can a Base44 app run on-premise?

  Yes, once it has a backend of its own. Base44 itself has no on-premise version, and every Base44 app runs on Base44's servers. EscapeBase44 moves your app, with its own backend and its own database, into one package that runs on a Linux server on your own infrastructure, inside your network, with nothing in it connecting to Base44.

• Does Base44's Enterprise plan support on-premise deployment?

  No. Enterprise adds SSO, an IP allowlist and audit logs, and none of it moves the app: the whole app keeps running on Base44's servers, exactly like on every other plan. The allowlist only decides who can sign in, and Base44's own support staff can get past it.

• Can I run my Base44 app on an intranet, a local server or our own hardware?

  Yes, after the move. It runs on one Linux server on your local network and answers on an internal address. Exporting the app onto an intranet server doesn't do it: the screens load from your server, and everything the app actually does still runs on Base44's servers. Without the internet, the whole app stops working.

• Can it run offline, on a network with no internet?

  Yes. Nothing in the install or in the running app needs the internet, so an air-gapped network is fine. Updates come in as a file, the same way the app did, and if the app uses AI, it runs on a model inside the network.

• Can my Base44 app run on Windows Server with IIS and SQL Server?

  Yes, on your Windows Server, in a Linux virtual machine that Hyper-V or VMware sets up in a few minutes. It doesn't run on IIS and SQL Server themselves, because that would mean rebuilding it. It can still read from and write to your SQL Server, since it sits inside the network with it.

• Will my users have to sign up again?

  No. Every account comes over with its role and its data. Each person just sets a new password the first time they sign in, or signs in with their company account.

• Can people sign in with their company accounts?

  Yes. If you want people to sign in with Microsoft Entra ID, Google, Okta or your own Active Directory, say so in the request. Then whoever leaves the company loses access the day their company account is turned off.

• Does EscapeBase44 need access to our network or our servers?

  No, never. You install it yourself from the runbook, start to finish, and I'm never on your server or your network. After that, nothing in the app connects to EscapeBase44.

• What leaves our network after the move?

  Nothing, day to day. The app, its database and its files stay on your server. Updates come from your repository, and the app's AI calls only leave the network if you run them on a provider's key rather than on a model inside it.

• Can the app reach our internal systems?

  Yes. It runs inside the network, so a backend function can call an internal database or API the way any internal app does. On Base44 it's the other way around: the app runs outside, and reaching an internal system means opening your network to the internet.

• Who maintains the app after the move?

  You do. It's your app and your code now, and the server runs like any other server you have. For the first 30 days I fix anything that works differently than it did on Base44, at no charge. After that, the code is in your repository, so any developer can pick it up.

• Can our security team review the code before it's installed?

  Yes. You get the whole codebase, backend included, before the install, so your security team can go through it like any other app they approve.

• Do you sign an NDA? Does our data pass through you?

  Yes. Every move runs under an NDA, signed before anything starts, and your data is only with me while the package is being built. Nothing is kept after that, and there's a data processing agreement if your legal team needs one.

• How are backups handled?

  Like on any other server you run. A copy of the database is saved on the server every day, and that copy and the uploaded files go into your normal backups. Everything else comes back from the code in your repository.

• Is there a log of who changed what?

  Every record keeps who created it and when it last changed, and the server logs every request it answers. If you need a full trail of who changed what, say so in the request.

• Can I keep building the app after it's inside the network?

  Yes. The code is yours, backend included, and it's a normal app, so you can change it any way you want, with any developer or with tools like Claude Code and Cursor. Each change goes live when the update script runs on the server.

• We're an agency or an MSP. Can each client run their app on their own server?

  Yes. Each client's app is its own package, installed on that client's own server, inside their own network. One client's app never touches another's.

• What do you need from us to start?

  Just the request below. After that, a read-only key to the Base44 app, which you delete when the move is done, and a few details about the server it will run on.

• How much does it cost?

  A fraction of what rebuilding the app would cost, paid once: no subscription, no monthly fee to me, and no Base44 plan afterwards. Send the request below and you'll have a quote within a day.