Taking a Base44 app to production starts with understanding the platform.

What Base44 builds for you, and what stays with the platform

Base44 generates the frontend, backend, database, authentication and hosting of an application from a conversation, which is why it is so fast for a first version. Wix acquired Base44 in June 2025. According to Base44's developer documentation, the frontend is a standard React app built with Vite that talks to the backend through the Base44 SDK. Data lives in entities defined by JSON schemas and stored in a MongoDB-compatible NoSQL database, and backend logic runs as Deno-based serverless functions written in TypeScript.

The important difference is the backend. Base44's documentation describes it as a managed platform for data, authentication, functions and hosting, and says backend resources are deployed to Base44's infrastructure. You can host the frontend elsewhere and keep calling the Base44 backend, but Base44's own site hosting supports single page applications only, without server-side rendering. This is a trade-off that buys speed, and production planning should start from it rather than discover it later.

Two-way GitHub sync is available on the Builder plan and higher. Changes made in Base44 are pushed to GitHub automatically, local changes reach Base44 when they are merged into the main branch, and a separate Publish makes them live. With this integration, entities are managed in Base44 and are not included in the local repository, so the repository is not a complete copy of the system. Agree on one place where changes are made and protect the main branch.

Permissions, secrets and platform-level risk

Base44 entities support Row Level Security, which controls which records a user can access, and Field Level Security, which controls which fields within a record they can see or change. A permission can allow everyone, block everyone or apply a condition, such as matching the record's creator or the user's role. Treat these rules as the real security boundary: hiding a button in the interface does not stop a direct API call. Backend functions that use elevated service role access need their own authorization checks, because the documentation makes the function responsible for them.

Base44's security scan is available on all plans and checks for issues such as data permissions, exposed secrets, unauthenticated backend functions and vulnerable dependencies. Secrets belong in the encrypted vault, which Base44 says is accessible only from the backend. Base44 also states plainly that you are responsible for your app's security settings.

Some risks sit with the platform itself. In July 2025, Wiz Research reported that a non-secret app ID sent to undocumented registration and verification endpoints could create a verified account on private Base44 apps, bypassing SSO. Wix fixed it in under 24 hours and reported no evidence of exploitation. The lesson is not to avoid the platform, but to design sensitive applications in layers: minimal data, server-side checks, audit logs and monitoring you control.

• RLS and FLS defined on every entity, tested with real user roles
• Every backend function reviewed for authentication and authorization
• Secrets only in the vault, rotated if they ever appeared in prompts or code

Environments, releases and recovery

On the Builder plan and higher, Base44 can keep test data completely separate from production data, and a testing link lets others try unpublished changes against the test database. The published app always uses production data. Note that running the local frontend against the hosted backend in remote mode writes to the live app's production data. We did not find a documented staging environment beyond test data, so ask whether test data is enough for your release process.

Build the release process around that: changes reviewed in GitHub, tested against test data, published deliberately and recorded. Because the data model lives in Base44 entities rather than in migration files, keep a written log of schema changes and check that existing records still fit after each one. Start automated tests with the flows that would hurt most if they broke: sign-up, permissions and payments.

Base44's documentation lists backups on the Elite plan with 7 days of retention and on the Enterprise plan with 30 days. Plan names and limits change, so check the current pricing page. Backups cover table data only; uploaded files and app users are kept separately and are not included. If your plan has no backups or the window is too short, run your own regular export and rehearse a restore.

Operations, cost and dependency on the platform

Production needs visibility you control: error tracking in the frontend and in backend functions, logs for important business events, uptime checks and alerts that reach a person. Watch performance as entities grow, and check how usage maps to your plan's limits and credits.

Then make the dependency explicit. The frontend in your repository is portable, but entities, authentication, functions and data run on Base44's infrastructure. The eject command creates a new project with a new backend on Base44 and copies entity schemas without the data. Apart from a local development server, we did not find a documented way to run the backend outside Base44, so plan a full move as a backend re-implementation plus a data migration, and confirm the current options with Base44. Staying can be the right decision, as long as it is a conscious one.

Privacy and compliance follow the data: know where personal data is stored, which processors handle it, whether your plan allows its use for model training and which agreements apply. Confirm these with Base44, along with its current terms on ownership of generated code.

A practical path: assess, secure, stabilize, then scale

The order matters. Every feature built on an unreviewed foundation makes later fixes more expensive.

• Assess: connect GitHub, map entities, permissions, functions, integrations, secrets and automations, and list which business flows depend on each.
• Secure: set and test RLS and FLS on every entity, add authorization checks to backend functions, move secrets to the vault and run the security scan.
• Stabilize: enable test data, define a reviewed release process, add tests for critical flows, error tracking, alerts and a backup or export routine you have restored from.
• Scale: improve performance and cost, decide deliberately what stays on Base44 and what moves, and keep developing on a stable base.

Questions to ask before launch

If any answer is unclear, treat it as work to schedule before real users and real data arrive.

• Who owns the GitHub repository, and who is allowed to publish?
• Can one user read or change another user's records through the API, not only through the interface?
• Which backend functions run without authentication, and is that intended?
• Where are secrets stored, and were any of them ever written into prompts or code?
• Does our plan include backups that cover our recovery needs, including files and users?
• How do we test a change without touching production data?
• What would it take to move the backend off Base44 if we had to?

How a dedicated engineering partner approaches it

UVISION has taken long-term responsibility for business-critical software since 2012, and we approach an AI-built application like any system we take over. We assess first: the code, the data model, the permissions, the release process, the business flows that depend on them and how much of it all depends on the platform. We keep what works, since much of what Base44 generates is a reasonable starting point, and fix the risky parts before adding scope.

Then we keep developing. Every project has at least one full-time developer who knows the system, working either as a dedicated developer inside your team or within a managed engineering engagement where we own delivery. We do not commit to timelines or outcomes before the assessment, because they depend on what the assessment finds.