Publishing an App

What publishing does

Publishing takes an App you built and puts it live on the web at its own URL — a real, working page anyone can open, no MotherFluxer account required. It is unique to Apps: of all the artifact types, only an App can be published.

Publishing is also the only way to share an artifact out of MotherFluxer. There is no public link, gallery share, or send button on Images, Videos, Audio, Documents, or 3D models — those live inside your account and your Projects. When you want something on the open web for other people to use, you build it as an App and publish it.

Everything below happens in the App editor's Publish panel.

Publish your App to the web

1. Open the App you want to share in its editor.
2. Open the Publish panel.
3. Select Publish to web.

Your App goes live and the panel shows its URL. From there you can:

• Copy the link to share it anywhere.
• Republish after you make changes — this pushes your latest edits to the same live URL.
• Unpublish to take the page offline. The URL stops serving until you publish again.

Republishing keeps the same address, so a link you already shared keeps working with your newest version.

Apps with many files publish completely

An App can be more than a single page — it can be split across several files, and features like install-to-home-screen add their own supporting files. When you publish, every one of your App's files goes live, not just the main one, so a multi-file App works exactly as it does in Preview. You don't do anything special for this; publish as usual and MotherFluxer serves the whole App. If you later republish, all the files update together at the same URL.

Save versions and publish from the Snapshot menu

Alongside the Publish panel, the App editor's Snapshot menu (the clock icon in the editor topbar) is where you keep named versions of your App — and where publishing also lives. Every version is a restorable point in your App's history that you can name, preview, and return to. There are two ways to make one:

• Save keeps a private checkpoint of your current draft — its code and its test data — without changing your live App. Use it whenever you reach a state worth keeping while you keep working.
• Publish does two things at once: it takes your draft live (the same result as publishing from the Publish panel) and records a version marking that release.

Naming a version is optional either way. A routine publish is labelled with its date; a version you name yourself stands out in the list, so save a name for the milestones you'll want to find later.

Browse, preview, and restore App versions

The Snapshot menu lists your versions newest-first. Each row shows when it was made, whether it saved code only or code and data, and — for a published version — a Live badge when it's the one your visitors are currently using, plus its GitHub commit if you've connected GitHub. From a version's row you can:

• Preview it to see that version's code without changing your draft.
• Restore it into your draft — either the code only, or the code and its saved data. Restoring data replaces your current test data; your live App is untouched.
• Make Live match to roll your App back to that version and publish it live in one step — the way to undo a release that went wrong.

Restoring is safe: bringing back an earlier version never deletes your newer ones, so you can always move forward again.

Collaborate on an App

The Snapshot menu's Collaborate section lets you invite other people to your App by email and give each of them Read or Edit access. Once someone accepts, their row shows whether the invite is still pending or accepted, and when they last opened and last edited the App — so you can see who's active. You can change a collaborator's access or remove them at any time.

Share the live URL, a QR code, or an embed

Once your App is published, the Publish panel gives you three ready-made ways to get it in front of people:

• Link — select Copy next to the URL to copy the address, then paste it into a message, post, or email.
• QR — select QR for a scannable code. Anyone can point their phone camera at it to open your App on their device — handy for handing it off in person or putting it on a slide or sign.
• Embed — select Embed for a snippet you can paste into another web page so your App appears right inside it. Select Copy embed code, then drop it into the page where you want the App to show. Before it will appear on that page, add the page's website to your App's allowed embed domains (see below).

These options stay greyed out until the App is published — publishing is the one prerequisite for sharing.

Control who can embed your App

By default, only your own App can display itself — no other website can put your App inside a frame on their page. This protects the people using your App: it stops a stranger's site from wrapping your signed-in App to trick or spy on your users.

To let a specific website embed your App, add that website to your allowed embed domains:

1. In the Publish panel, open the Embed option.
2. Under Allowed embed domains, type the website that will host your App — for example, example.com — and select Allow domain.
3. Repeat for each website that should be able to embed it. Remove a website any time by selecting the ✕ next to it.

Until you add a website here, the embed snippet will show nothing on that page. Once the website is on the list, your embedded App appears there normally.

Connect a custom domain

By default your App lives at the URL MotherFluxer gives it. You can put it on your own address instead — like app.yourdomain.com.

1. In the Publish panel, select Domain.
2. Enter the address you own (for example, app.yourdomain.com).
3. Select Connect domain.
4. Add the DNS record shown to you at your domain registrar, then select Check status.

Once the connection verifies, your App is served securely from your own domain. You can remove a connected domain at any time and fall back to the default URL.

Add accounts and in-app AI to a published App

A published App can do more than display — from the Publish panel you can give it sign-in and its own AI, so it behaves like a real product for the people who use it.

• Accounts — turn on Require sign-in so people sign in to your App with an email and password before using it. This is free, and it lets your App know who each visitor is. From the Publish panel you can see everyone who's signed up and manage their accounts (including password resets and deletions).
• In-app AI — turn on Enable in-app AI to give your App its own assistant that your visitors can talk to. You set its persona (how it behaves), pick from the model options shown, and set spending budgets and rate limits so usage stays within bounds. Replies can come back all at once or stream in word-by-word for a live, typing-style feel. AI usage is billed to your credits, so start with conservative budgets. Because a published App is open to the public, anyone using it can trigger the AI up to the limits you set.

Both of these only apply after the App is published.

Set usage alerts for your App

A published App uses resources as people interact with it — computing time, outgoing requests, emails sent, database writes, and stored data. From the Publish panel's Usage alerts you can set an advisory cap on any of these so you're warned before usage climbs higher than you expected. Leave a field blank for no alert on that measure.

These caps are advisory, not hard stops: when usage crosses most of the cap you set, MotherFluxer raises a one-time heads-up, and your App keeps running up to the platform's own built-in ceiling — the alert is there to catch a runaway or an unexpectedly popular App early, not to switch it off. Set the caps that make sense for your App, or leave them blank to rely on the platform ceiling alone. They only apply after the App is published.

Require a verified email for sign-in

When you turn on Require sign-in, people can sign up with an email and password and start using your App right away — by default they do not have to confirm their email address first. A sign-up email is therefore not, on its own, proof that the person actually owns that address.

If that matters for your App, turn on Require verified email (it appears under Require sign-in once sign-in is on). With it on, a new user must click the confirmation link sent to their email before they can sign in — so everyone who gets in has a working, confirmed address. Leave it off and anyone can sign in immediately with any email they type, verified or not.

Deciding whether your App needs verified emails is your call as the builder. The confirmation link is sent automatically when the setting is on; email is not verified by default.

Let visitors sign in with a phone number

When your App requires sign-in, you can offer phone sign-in as well as email: a visitor enters their phone number, gets a one-time code by text, and types it in to sign in — no password to remember. Because the code is sent to their phone, a signed-in phone number is a confirmed one.

Phone sign-in is delivered by MotherFluxer, so you don't need to connect a texting service for it. It's separate from sending your own text messages from your App's code, which uses a connected SMS service instead.

Optional: give your App a database

If your App needs to remember things between visits — saved entries, lists, user data — you can add a database from the Publish panel's Data controls. This is a paid add-on with a flat monthly price shown to you before you confirm, and the storage pool is shared across all of your Apps. You choose whether everyone shares one dataset, each visitor gets their own, or each signed-in account gets a private one. You can turn it off at any time, and your data is kept if you do.

Who can see your App's data

When your App has a database, the Each visitor sees control decides how its data is split between the people using your App:

• Shared — everyone who uses your App reads and writes one common dataset.
• Per visitor — each visitor gets their own separate dataset, kept apart by the browser or device they're using.
• Per account — each signed-in person gets their own private dataset tied to their account. This option needs Require sign-in turned on.

"Per visitor" is a convenience, not a privacy wall. It separates data so each browser sees its own copy — but a visitor is identified only by the browser or device they're on, never by a confirmed identity, so that separation is not something to rely on for security. Do not use Per visitor to hold anything private or sensitive. For data that must be genuinely private to one person, turn on Require sign-in and use Per account, which keeps each account's data locked to that account and enforced by MotherFluxer.

Anything under Shared is readable by everyone who uses your App — treat it as public to your App's audience. Choosing the right option for the data you store is your responsibility as the builder.

Your App's Test data and Live data

When your App has a database, its data comes in two copies you switch between in the editor's Data view:

• Live data — what real visitors read and write on your published App. This is the real thing.
• Test data — a private working copy, for you and the App's building assistant to try changes against while you edit. Anything you do here never touches what your visitors see.

A toggle at the top of the Data view — Live data / Test data — shows which copy you're looking at and editing, so you always know. A change to Test data stays in Test data; a change to Live data is your real, live data, and the editor asks you to confirm before anything live is changed. Your Test data starts as a full copy of your Live data, so you're always working against realistic content instead of an empty table.

Refresh your Test data from Live

Your Test data does not stay in sync with Live automatically — it's a working copy you control. When you want to pull in the latest real data to test against, select Refresh from live in the Data view.

Refreshing replaces your Test data with a fresh copy of your Live data. Two things to know before you do it:

• Any test-only edits you'd made to this data are lost — that's the point; you're resetting the copy to match Live.
• Your pending structure changes are re-applied on top, so the refreshed copy still matches the App you're building, not the old shape.

Refreshing never touches your Live data — it only overwrites the test copy. The editor asks you to confirm first.

Publish changes to your live data without downtime

When you change your App's data structure — rename a field, add a new one — and publish, MotherFluxer updates your Live data to the new shape automatically, with no downtime. Your App keeps serving visitors the whole time, and no field ever goes blank while the change rolls out — even on a large App with a lot of data. You never have to take your App offline or migrate anything by hand.

Renaming a field keeps the values that were in it — they move to the new name. Adding a field with a starting value fills that value into your existing records. Before publishing a change that could affect data already in your live App, the editor shows you exactly what will change and asks you to confirm.

Hide sensitive fields from your Test data

Because your Test data starts as a copy of your real Live data, it can contain real personal information — and that copy is what you and the App's building assistant work against while you develop. If you'd rather keep certain fields out of it, you can mask them.

In the editor's database controls, under Mask fields in test data, select any field whose real values you want hidden. A masked field's values are blanked out when Live data is copied into your Test data, so the real values never appear in the working copy. This is off by default — nothing is masked unless you choose it.

Masking takes effect the next time your Test data is copied from Live — when you publish or refresh from live — not retroactively on data already copied. It only affects the Test copy; your Live data is never changed by masking.

Run SQL against your App's data

When your App has a database, the Data view has a SQL tab where you can run SQL directly against your App's own data. You get full read and write access to your App's own tables, plus a read-only mf_data view of the records your App saves. Type a statement and press ⌘/Ctrl + Enter (or click Run) to run it; results come back in a table below. Your App keeps working through its built-in data tools regardless — the SQL console is a power-user tool for working with your data directly.

Running SQL can incur cost, so it needs a verified payment method on the App's owner. Until that's in place, the SQL tab explains how to turn it on and the Run button stays off.

The SQL tab appears only while your App is on the shared database. If you've upgraded your App to its own dedicated database, work with it through that database's own direct connection details instead — shown in the Publish panel.