WeWeb Review: Frontend Export or Fullstack Self-Hosting?

WeWeb combines AI assistance with visual app editing, workflows and backend connections. It suits a team that wants to keep changing an app visually while choosing where it runs.

Product capabilities below come from current official documentation. On November 3, 2026, I also ran WeWeb’s official built export sample locally.

That archive was last modified in February 2024; it does not establish how a current fullstack export behaves.

The customer-ticket migration remains a proposed evaluation. I did not test a paid workspace, native backend, authentication migration or R2 connection.

Keep an existing backend when the interface is what needs to move

WeWeb can use an external backend or its built-in Data & API workspace for tables, views, APIs, users and roles. A separate backend is a choice, not a requirement.

For a customer portal over an established backend, I would first evaluate an interface-only export. Keep record permissions in that backend and verify the exported app still respects them.

The Cloudflare guide covers built interface files on Cloudflare Pages. Database, authentication, storage and other backend services require separate hosting.

Moving the interface does not move the whole system. Record every service the login, ticket form and attachment flow call before choosing a production host.

For an interface-only export, the current export documentation says the application continues calling its backend and external services.

Inventory those endpoints rather than treating a successful page load as proof that the whole system moved.

Exporting the native backend needs a migration plan

WeWeb currently documents a fullstack AWS deployment using separate interface and backend archives.

Its reference setup uses S3 and CloudFront for the interface, EC2 for the backend and RDS PostgreSQL for data. This gives a team more infrastructure to operate.

The current export guide says WeWeb Auth runs inside the exported backend, with users, sessions and roles in your database.

Integrations also connect from that backend to their providers. That is different from moving only the interface.

Export access still leaves several jobs for the maintainer:

• Supply integration keys and the authentication secret; the export excludes secrets.
• Migrate existing database records. Exported table structure is not a copy of the records.
• Move previously uploaded files into your own storage.
• Supply your own AI-provider keys and email integration where needed. WeWeb AI credits and built-in email sending do not carry over.

Two qualifications should affect your decision:

• Authentication setup is outside that guide’s scope. Resolve the target login and session arrangement before relying on it for a customer portal.
• A ready-to-run SQL schema file is conditional. The guide says to use your own schema or migration process if the current export lacks one.

I would request a sample export before committing to the migration. Have the future maintainer identify the schema procedure and authentication owner from actual files.

Treat a working backend health endpoint as an infrastructure check. It does not demonstrate that customer records, sessions or private attachments survived the move.

What survived in the official sample on a local host

I downloaded the built ZIP linked from the export guide, extracted it and served it on a local static server.

Opening /accordion/ directly loaded the page; clicking its first Title revealed Text. Refreshing loaded that route again, with the accordion collapsed.

That is one useful interface check: a direct URL and a working interaction survived outside WeWeb hosting. This older Starter Kit sample is not a customer portal, a new AI-generated app or evidence of a completed backend migration.

Inspecting the sample’s HTML also found external Google Fonts and WeWeb-hosted icon stylesheet URLs.

A downloaded archive is not proof of an offline-ready application. Audit external assets separately; I did not run a network-isolated test.

A shared ticket link should survive refresh and reject the wrong customer

The October 14 changelog says AI-generated detail pages now carry the record ID in the URL and reload the matching record after refresh or sharing.

That is useful for a support portal: an agent should be able to send a ticket link instead of asking the customer to find it again.

In the proposed trial, create one ticket per test customer. Copy the first customer’s detail URL, open it directly on the target host and refresh it.

Then open that URL as the other customer. The backend must deny the unauthorized record request, even if the interface hides the ticket in its list.

A refresh that returns 404 points to a different problem. WeWeb’s routing guide explains why in-app navigation can work while a direct request fails.

On a host with custom routing, preserve API routes and assets before adding an SPA fallback. Confirm the detail page and API request separately.

If the page loads but shows the wrong ticket, inspect the URL-to-record binding and response. A fallback can repair routing without repairing the data query.

The same release favors inspectable built-in backend actions such as Select rows and Update rows. Review the generated action and its conditions before accepting the workflow.

Plan the second release before accepting the first export

WeWeb’s export documentation cautions that exported code is machine-structured, difficult to edit directly and cannot carry external changes back into the visual editor.

I would keep the visual project as the editing source unless the receiving developer explicitly accepts a different maintenance process.

For the interface route, the Cloudflare guide documents this sequence:

1. Publish the project at least once, then use Publish → Export → Generate code export.
2. Open the project’s Deployments tab and find the exported version.
3. Download built Interface files from that version’s menu and deploy the archive to the chosen host.
4. Make a small follow-up change in WeWeb, publish and export again, then verify it on the deployed app.

These are documented labels, not a live-account UI test. The AWS guide calls the entry point Deploy; check the current export controls in your workspace.

A useful follow-up change is adding a ticket status. Check the field, saved value and detail link after redeployment, so the team rehearses more than an upload.

Store customer attachments where the deployed app can keep using them

WeWeb warns that files uploaded to its CDN are not preserved for a self-hosted app. Establish independent storage before collecting customer attachments.

In the ticket trial, upload an attachment before export and open it afterward. Test private access as both customers; a visible filename does not prove correct file access.

WeWeb announced R2 support on October 28, 2026 for its Data & API storage. Its current R2 guide requires different buckets for public and private files; a private-only app can leave the public bucket empty.

An empty environment is not necessarily an isolated environment. The guide says an unconfigured Production connection falls back to Staging, then Editor. Assign the intended connection explicitly before using real customer files.

When the app moves to another domain, recheck upload CORS. The documented checks distinguish bucket access, browser uploads and public links; passing one does not establish the others.

These are documented conditions, not results from my sample test.

Compare alternatives by who will edit the next release

Choose according to the next maintainer’s preferred workflow:

• Consider Lovable when a conventional repository handoff drives the choice.
• Consider v0 when a developer wants to continue in a Next.js workflow.
• Consider Base44 when a contained managed-backend workflow fits better than operating more infrastructure.

Use our code-export guide to compare what an artifact includes before treating download access as a maintenance plan.

Price the editor and production operation separately

The pricing documentation lists code export from the Essential workspace plan upward. Workspace capabilities, developer seats and WeWeb Cloud hosting serve different purposes.

Self-hosting removes the need for a WeWeb hosting plan. Budget for an eligible seat plan when you need fresh exports, plus your infrastructure and connected services.

For a native-backend move, include database operations, file storage, monitoring and recovery work. Assign those tasks to a named maintainer before comparing subscription totals.

WeWeb’s routing documentation also says standard plans do not include support for custom self-hosting setups. Include hosting support in that ownership decision.

Next step: prove the customer-ticket journey on your intended host

Build a small portal over test data, then deploy the relevant export to the host you would actually use. Keep a record of the result for each condition:

• A shared ticket URL loads the correct record after a fresh visit and refresh.
• Another customer cannot read or change that ticket through its API.
• Login and session renewal work on the destination domain.
• An existing attachment remains reachable only by its intended audience.
• The maintainer can explain remaining managed-service dependencies.
• A follow-up status-field change reaches production through the agreed release process.

For a native-backend export, also require a demonstrated schema setup and a decided authentication implementation. Choose WeWeb once the required journey passes and someone owns its next release.