Publishing an app

The preview is a development server. It is fast, it hot-reloads, and it is not something you send to anyone. Publishing turns your app into a real static website that Bookbag hosts at a public address.

What publishing actually does

It is not a copy of the preview. Publishing runs a production build of your app and exports it as a static site — plain HTML, CSS and JavaScript with no server behind it.

Step by step:

1. If a build is running, publishing is refused: "A build is running — publish once it finishes."
2. If your project has no address yet, one is generated from its name.
3. The sandbox is started if it was asleep.
4. Your next.config.mjs is temporarily replaced with a publish-only configuration — static export, the right base path, unoptimised images.
5. next build runs, with a 10-minute limit.
6. Your original next.config.mjs is put back, whether the build worked or not.
7. The exported site is copied to Bookbag's hosting area and the project is marked published.

Steps 4 and 6 matter: the export is built into a separate folder so your running development server is untouched. Your project's own config is never permanently changed.

The first publish takes about a minute. You wait while it happens — there is no queue and no email when it is done.

How to publish

The Publish button sits in the project page's top bar. It opens a dialog titled Publish <your project name> with this description:

Bookbag builds your app as a static site and hosts it at a public address. It stays up even when the editor preview is asleep.

Inside:

• Address — a text field with a fixed /p/ prefix in front of it, showing your slug.
• Publish — the primary button. Once you are live it reads Publish update.
• Take offline — appears once you are live.

While it works: "Building your app for production — this takes a minute the first time."

On success a green bar appears with your full URL, a copy button and an open-in-new-tab button, and a toast reads Your app is live.

The published address

Your app is served at:

https://app.bookbag.ai/p/<your-slug>/

The /p/ prefix is fixed. The slug is the part you choose.

The published site is completely public. There is no sign-in in front of it. Anyone with the link can open it, and search engines can find it. Do not publish an app holding anything you would not put on a billboard, and run the security check first.

Choosing an address

Type into the Address field and press Save. The rules:

• 2 to 40 characters.
• Lowercase letters, digits and hyphens only.
• The first character must be a letter or digit, not a hyphen.

Anything else is refused with:

Use 2–40 characters: lowercase letters, numbers and hyphens, starting with a letter or number.

Slugs are unique across the whole platform. Taking one that is already used gives you:

That address is taken.

On success: Address updated.

Renaming a live address moves the site rather than rebuilding it, so the change is instant and the old address stops working immediately.

The address you get by default

If you publish without choosing one, Bookbag builds a slug from your project's name: lowercased, with everything that is not a letter or digit turned into a hyphen, cut to 40 characters. A project with no usable name becomes app.

Eight words are reserved and get -app appended if your name would collide with them: admin, api, auth, dashboard, project, account, p and health.

If the result is already taken, a short random suffix is added.

Auto-generated addresses are rarely what you want to share. Set one deliberately before you send the link to anyone.

Publishing again after a change

Publishing takes a snapshot. Nothing republishes automatically. Build ten more things into your app and the published site still shows what it showed at the last publish.

To update it, open the dialog again and press Publish update. The button in the top bar reads Published rather than Publish once you are live, which is the quickest way to check whether a project has been published at all.

When publishing fails

The error is shown inline in the dialog in monospace, and as a toast reading Could not publish.

Message	Meaning
The production build failed: followed by output	next build failed. The last 2,500 characters of its own output follow, and they name the file and line. Paste the message into the chat and the builder will usually fix it.
The export produced no index.html — the app may use server-only features.	The build succeeded but produced no home page. This means the app uses something a static export cannot do. Ask the builder to make the app work as a static site.
A build is running — publish once it finishes.	Wait.

A common cause of the first message is code that works fine in development but not in a production build — an unused import of a file that no longer exists, for example. The development server is forgiving about these; next build is not. This is a good reason to publish early and often rather than only at the end.

Who can publish

Owners, admins and members of the organization that holds the project, and the project's creator. Viewers cannot publish, republish, take a site offline, or change its address — those are all writes.

Next

• Managing a published app — taking it offline, and what happens to the address.