Deployments

Publishing takes what you have built in the editor and puts it online, at a real URL your users can open. Everything you do in the editor stays private until you publish, so you can experiment freely without touching the version people are using.

Your environments

A WeWeb project has up to three environments, and each one keeps its own data:

• The editor is your sandbox. This is where you build, and where you can break things safely.
• Staging is a published copy for testing. You share it with your team to review a version before real users see it. It is available when your plan includes staging.
• Production is the live app your users open.

Because the data is separate, adding a test record in the editor does not create it in production. You choose whether to copy data across when you publish.

Publishing your app

1. Click Publish at the top right of the editor.
2. Keep the Publish option selected (the Export option next to it is for downloading your code).
3. Choose where you are publishing to.

If your plan includes staging, the panel shows the three environments stacked in the order a version travels through them:

• In the Editor environment card, click Publish to staging to push what is currently in your editor.
• In the Staging environment card, click Publish to production to promote the version that is already in staging.

If your plan does not include staging, you get a single card with a Publish your app button that goes straight to production.

Each card shows whether that environment is Live or Offline, which version it is running, who published it and when, and the URL. The pencil icon next to the URL lets you change your WeWeb subdomain.

WHY PUBLISH TO STAGING FIRST

Staging lets you click through the real published app, with real data, before your users see it. Bugs that only show up outside the editor (a redirect, a slow query, a workflow that behaves differently once published) surface here instead of in production.

Once you pick an environment, you can describe what changed:

The comment is optional, but it becomes the Message of that version in your publication history, so it is worth a short sentence. Click Publish to start.

WARNING

Publish to production is disabled when there is nothing in staging yet, or when staging and production are already running the same version. Publish to staging first.

Choosing what happens to your data

If your project uses the WeWeb database or storage, publishing asks what to do with your data before it starts. Your changes always go live. Your data only moves if you say so.

You get two choices:

• Keep production data Keeps what is already there, which is almost always what you want. Only your changes go live.
• Copy editor data to production Replaces the target with what is currently in your editor. You pick what gets copied: Database (data, schema & users), Storage (files & assets), or both.

Copying is useful the first time you publish, when production is still empty and you want your starting data in place. After that, it overwrites what your users have created, so use it deliberately.

If your publication includes changes to your database structure (a new table, a renamed column), WeWeb analyzes the change and tests it against the target database first, then asks you to approve it. This is why publishing is something you trigger yourself rather than something an AI agent does for you.

Publication history

Every publication is kept, so you can see what went out and when.

1. Open the Settings tab in the top bar.
2. Open Publications.

Each row is one version:

• Version Is the version number, counting up from v1.
• Status Shows where that version currently lives: In Production, In Staging, or Exported for a version you downloaded rather than published. A publication in progress shows Publishing, and one that did not go through shows Failed.
• Message Is the comment you wrote when publishing.
• Created By And Created At tell you who published it and when.

The search field above the table filters on the message, which is another reason to write one.

To see what happened during a publication, and to read the logs of one that failed, open the three dots menu at the end of the row and choose See logs.

Restoring a previous version

If a publication turns out to be a bad one, you can put an earlier version back in production without rebuilding anything.

1. In Publications, find the version you want to go back to.
2. Open the three dots menu at the end of its row.
3. Click Restore version vX to production.
4. Confirm with Restore.

Your current version is not lost. It stays in the history, so you can restore it again once you have fixed the problem.

PLAN REQUIRED

Version restoring depends on your project plan. The Your project plan panel next to the table tells you whether it is included, and gives you an Upgrade plan button if it is not.

Restoring changes what your users see. It does not change your editor. If the problem came from something you built, fix it in the editor, or roll the editor back to an earlier backup.

Learn more about editor backups →

Downloading your project files

If your plan includes code export, the three dots menu on a version also lets you download it: Download built Interface files and Download built Server files for the compiled app, and Download source Interface files and Download source Server files for the source.

Learn more about exporting and self-hosting an app built in WeWeb →

Error logging

Once your app is in production, it helps to know when something breaks for a real user. You can connect an external error logging service such as Sentry to your WeWeb application.

We will cover this in more detail later. In the meantime, this community forum post walks through setting up Sentry with a WeWeb app.

CONTINUE LEARNING

Publishing controls what your users see. Editor backups control what you see while you build, and let you undo a change that broke your project.

Backups →