Publishing an App

What publishing does

Publishing takes an App you built and puts it live on the web at its own address — 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 different from the other ways to share. A share link shows any artifact to the people you send it to, and posting to the community lists it in the Slop feed; only publishing gives an App its own address on the open web, as a working page anyone can use. When you want something on the open web for other people to use, you build it as an App and publish it.

Publishing happens in the App editor's Manage tab, in Publish. Only an App's owner can publish or unpublish it — for a collaborator, those controls are simply not there.

Publishing needs something that can go live — a web page (an HTML file, or a framework App that builds one), a server, or an action. Which file you have open never matters. An App made only of notes, diagrams or data files still previews in the editor, and Publish says what it needs instead: Nothing to publish · add a page, a backend or an action.

How many Apps you can have live

Every account can build up to 100 Apps and have 25 of them live on the web at once. Both are generous for one person's work, and neither costs anything — they exist so an allowance that is shared across all of your Apps cannot be multiplied by making more of them. If you reach the live limit, unpublish an App you no longer need and the next publish goes through; nothing already live is ever taken down to make room.

An App you post to Slop, and the App a co-op you start runs, are Apps of their own, so each one counts toward both limits too.

The Publish screen: your Draft, the changes, and Live

Open your App, choose Manage, then Publish. It shows three things side by side, or stacked when the space is narrow:

• The Draft card — your private working copy, running, with its one status and its address. Press the status, or the card's Settings icon, to open the Draft window.
• The changes between them — how many things differ between your Draft and what is live, with the Publish and Discard buttons right under the count. Both act on exactly those changes.
• The Live card — your App as a visitor gets it, with its one status and its address. Press the status, or the card's Settings icon, to open the Live window.

Each address under a card starts with https://, so it reads as the web address where that version lives. While an address answers, the copy icon beside it copies that link in one press.

Under the cards, Search shows how your App appears when someone finds it in a search engine: whether it is Listed, and the title, address and description a search result shows. Its Settings icon opens the window where you change them.

Publish your App to the web

1. Open your App, choose Manage, then Publish.
2. Look at the changes container between the two cards. Before your first publish it reads New app; after that it counts what is waiting, such as "3 changes".
3. Press Publish under the count, check the review, and confirm. To see what is waiting first, open the container (below).

Your first publish gives your App its address and says "Published — anyone with the link can open it". Every publish after that updates the same address — "Your changes are live" — so a link you already shared keeps working with your newest version.

Publish is offered whenever there is something for it to do: changes are waiting, your App is not on the web, or Live is still serving an earlier page. When your Draft and Live match and Live is working, the changes container says Synced and there is nothing to press.

See what publishing would change

Press the count to open the changes container. It takes the whole screen — the Draft and Live cards and Search step aside until you close it — and lists one row for each thing that differs, named the way you made it — a page, a list, a group, an action, a schedule, a variable, a file you uploaded, a feature, a dashboard you rearranged, or the settings screen you changed, such as Sign-in and limits. Each row says whether it is New, Edited or Removed. Press a row to see what changed in it, side by side with what Live has now: a page's or a file's code, or a setting's own value. Publish and Discard sit under the list too. Press the count again to close it.

Two other answers are possible: Changed means your Draft differs in a way that cannot be listed row by row (Cannot be counted), and Not known yet means your Draft could not be read yet.

The review before your App goes live

Pressing Publish opens a review: a few lines, each one fact about what this publish does. It is titled Publish to the web when this publish puts your App online, and Publish changes when it updates an App that is already live.

• Setup needed — first, while a key your App requires has nothing set up for Live. It names each missing variable, and Publish stays off until they are set; Set them up takes you to them (below).
• Build — for an App that is built before it can go live (one made with a framework), while that build isn't ready: Waiting while your latest changes are still being built, Failed when the build failed. Publish waits until the build is ready and frees itself the moment it lands, so you never publish an earlier build by mistake. A failed build has to be fixed first; the Draft window says why it failed.
• Goes live — what goes up. The whole app when this publish puts your App online; otherwise how many files and settings differ from Live, such as "3 files · 1 setting". Nothing new · re-deploys means Live already matches and publishing serves the same App again, and Changes means your Draft differs in a way that cannot be counted.
• Lists — shown when the publish changes your lists, with how many it adds, changes and removes in Live, such as "1 added · 2 changed". Your code and the structure it needs go live together: a new list, a new field or a renamed one is published with the code that uses it.
• Who can open — Anyone with the link. To limit who can use your App, add a sign-in inside it.
• Live data — Kept. Publishing never copies your Draft's records into Live, and a backup of Live's data is taken automatically before every publish.

Press Publish to go ahead, or Cancel. If a publish is refused, the review says why.

A key your App needs must be set up before it goes live

Your App can declare a variable it requires — a payment key, a maps key, a connected account. While one of those has nothing set up for your Live App, your App can't go live: every feature that reads it would fail for the first visitor who tried it.

• The review names them. Its first line, Setup needed, lists each missing variable by name, and Publish stays off.
• Set them up takes you to Equip › Connect, where the Variables list leads with each one marked Setup needed. Open one to pick a key from your vault, add a new one, or connect the account it needs, then publish.
• Every way of going live checks it. A version that still needs a key is refused by name, whichever way you publish it.
• Only required keys hold a publish. A variable your App can do without never stops it.

When you open an App with a required key missing, the editor goes to that list by itself, once.

When a publish could change or remove live data

Publishing your App never copies your Draft's records into Live, but a change to your lists can still affect the data Live already holds — a list or a field removed, or a field's type changed. When it could, the review you get on pressing Publish says so on its Live data line, which reads Changed or removed, with the Lists line marked the same way. Under it, the review names each change that could lose data, and Publish stays off until you tick Change Live’s data.

What you tick covers exactly the changes on screen. If your Draft changes while the review is open and those changes are different by the time you press Publish, nothing is published: the review reads them again and asks you to tick it again.

If a key in your code would be public, publishing stops and asks

Anyone who opens your published App can read the code it sends to their browser — that is what a web page is. So when you publish, we read that code for values that can only be a secret: a Stripe secret key, an AWS access key, a private key, a GitHub, Slack or SendGrid token, a Google service-account file, a database's admin key.

If one is there, the publish stops and the review says what it found and which file and line it is on. Nothing goes live, and we never edit your code for you.

You have two ways forward, and the review offers both:

• Open the vault — a button beside the review's own, which takes you to Equip › Connect. Add the value there as a key in your Variables list, take it out of the file, and read it from an action instead. The value stays in your vault and never reaches a visitor.
• Publish anyway — the review's Publish button becomes this, for a value that is genuinely meant to be public. We remember that answer for this exact code, so you are not asked again; change the code and we check it once more.

Keys that are public by design never stop a publish: a Firebase browser key, a database's public browser key, and a Stripe publishable key all belong in a page and are left alone.

This check runs when you publish to the web, and on your Live version only — your Draft is visible to you and your collaborators alone, so its code is not exposed to anyone. A key's value typed or pasted into a file is refused when the file is saved, with Declare and vault it to move it where it belongs, so this check mostly finds a key that was in the code before that.

Discard your Draft's changes

Discard, in the changes container, throws away what is waiting and resets your Draft to what Live serves. The confirmation lists what it does: Unpublished code is Discarded, Draft data is Cleared when your Draft has data of its own, and Live app and its data are Untouched. Confirm with Discard changes, or choose Keep editing.

Discard appears once your App has been published and something is waiting. A collaborator can discard too — it changes nothing a visitor sees.

What the Draft and Live statuses mean

Each card shows one word for where that part of your App stands:

• Draft — Ready, Not built, Updating, Problem, or Stopped when your App is unpublished.
• Live — Working, Limited, Paused, Down, Problem, or Unpublished.

The word never stands alone. Its window lists every reason behind it, one line each: the part of the App it is about, what is the matter, and who or what ends it — Yours to change, The owner’s to change, a time it clears, Support releases it, or We are on it. For example, a Page line reading "Behind · the earlier page is served until the next publish" means Live needs one more publish to catch up, and an Assistant line reading "Paused · today's limit reached" means your App's assistant stopped answering for the day.

The Publish tile says the same in one word — Synced, a count of changes, Updating, Paused, Problem or Unpublished.

The Manage tab's mark

While your App is live, the Manage tab carries a mark whenever there is something to look at in Publish, even with the menu closed: Changes waiting, Live has a problem, or both. There is nothing else to watch for — no bar or reminder along the bottom of the editor.

The Draft window and the Live window

The Draft window holds everything about your private copy:

• Status — a line for each part: its Build when your App is compiled (with a rebuild), its Preview (with a retry and a way to open it in its own tab), and its Backend when your Draft runs a server.
• Preview — the Size every preview of your App is framed in.
• What your Draft and Publishing cost.

The Live window holds everything about your published App: its Status, its Address, its Domain, Share, Hosting with Background power, the Home screen install, and Unpublish. Under Status, Published says when your App was last published. A collaborator's Live window shows only the status, sharing and the home screen.

Unpublishing takes your App off the web and keeps it

Unpublish is reversible, and it deletes nothing. Open the Live window and choose Unpublish; the confirmation, Unpublish this app?, lists what happens:

• Address, sign-in and actions — Stop answering.
• Draft — Stops too. Your preview says Your app is unpublished.
• Data, accounts and settings — Kept: your App's data, its users' accounts, the keys it is granted, its settings, its address and its publish history.
• Your app and storage allowances — Still count. Deleting the App is what frees those.
• Background power, when it is on — Off until you publish again · billing stops.
• Its own database, when it has one — Back to the shared one · $5 a month stops. Your data is carried across and checked first, never thrown away.
• Your own domain, when one is connected — Released. You keep the domain itself; connect it again after you publish.

While your App is off the web, its schedules are held until it is published again, and paid upgrades wait too — where one would be turned on, the window says Publish again first. The Draft card says Stopped; the Live card says Unpublished, with Stopped beside its address. In both windows the Publish line reads Unpublished, with a Publish button beside it that brings your App back at the same address.

Deleting the App is the permanent one. That destroys its data, its users' sign-ups and its own database, and none of it comes back. Unpublish when you want it off the web; delete when you want it gone.

Your App's Draft and its Live version

Every App has two versions of itself, deliberately kept apart:

• Live is what the world sees at your App's address.
• Draft is your private working copy, at its own address — the copy icon on the Draft card copies its link.

A Draft has its own data, its own sign-ups and its own copy of your automations, so nothing you try there can reach a real visitor's records. Publishing is what moves your Draft to Live, and nothing else does.

Keys are the one thing that carries across, deliberately: your Draft reads the keys granted to your Live App, so you never re-enter a key to test. That also means a Draft calls the same real outside accounts your published App does — use a test account at the service itself when you're trying something that sends or charges for real.

A published App isn't showing my latest changes

When you edit an App after publishing, the live version doesn't update automatically. The published page keeps showing the version you last published, and the Manage tab carries the Changes waiting mark.

• Open Manage › Publish, check the changes container, and press Publish to push the current version live.
• Refresh the published page after publishing to confirm your changes appear.

Every change you want visitors to see needs a fresh Publish. A few settings are the exception and reach Live the moment you save them — those say Live at once where you set them.

Apps with many pages and files publish completely

An App is a whole project, and publishing puts the whole project online — every page and every other file — so it works exactly as it does in the preview. You don't do anything special for this; publish as usual. Publishing again updates every file together at the same address, and a file you deleted stops answering.

• Every page answers at its own address. Your front page is at /. Another page answers at its name without .html: about.html is at /about, and docs/index.html is at /docs/. The .html spelling works too.
• Every other file answers at its own path — a stylesheet, an image, a Markdown note at /docs/guide.md, a data file at /data/items.json, and a picture, video or other file you uploaded to your App at /assets/<name>.
• Some files never go online. Anything in a folder or file whose name starts with a dot (like .env) and the platform's own MotherFluxer folder stay private. The one dot folder that does go online is .well-known, the standard place websites publish files for other services to find. A key's value never belongs in a file at all: keep it in your Variables list in Equip › Connect.
• Your front page is the page named index.html at the top of your App — the page visitors land on at /, as on any website. To change your home page, edit index.html (or ask the AI to). An App with no index.html has no front page: / shows "This app has no front page", while its other pages still open at their own addresses.

A server App publishes without a web page

An App that runs its own server — in any language, with its own Dockerfile or a Node start script — does not need an HTML page at all. Turn the server on in the Live window, under Background power:

1. Choose whether it serves Live or your Draft.
2. For Live, choose how it idles, each with its monthly estimate: Rest costs next to nothing while idle and wakes in a second or three on the next visit; Awake has no wake delay and is paid while idle. A Draft server always rests.
3. Press Turn on. Before anything starts you see what it gives and what it costs; a Live server starts a Draft copy of itself too.

Then publish: your App's address answers from your server. While the server is off, the editor's preview says the App has no web page to show and points you to Manage › Publish.

When an App has both a server and pages, the server answers its address, and its pages are published beside it together with the stylesheets and scripts those pages load; the server's own code never goes online. An App runs a server when it says so: it has its own Dockerfile, its package.json has a start script, or it has a file named server.js.

Save versions from the File menu

The App editor's File menu, after the three tabs on the left of the top bar, is where you keep versions of your App. 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, then Save draft, keeps a private checkpoint of your current draft — its code and its data — without changing your live App. Use it whenever you reach a state worth keeping while you keep working.
• Publish, under Manage › Publish, takes your draft live and records a version marking that release.

Naming a version is optional either way: the Name field stands at the top of the Save list and in the publish review. 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 File menu shows your versions as cards, newest first, each with its name and a picture of its front page, marked Live when it's the one your visitors are currently using. Press a card to see that version; Restore then appears at the bottom of the menu. Its list ends with what the version holds: whether it's a private Draft checkpoint, when it was made, whether it saved code only or code and data, how many saves it contains — every edit MotherFluxer recorded between the previous version and this one — and its GitHub commit if you've connected GitHub. With a version on screen you can:

• Read that version's code without changing your draft, and press View to flip to Diff to compare it with your draft. Your running App stays as it is behind it: closing the File menu takes you back without reloading your App, and your undo history is kept.
• Restore it into your draft — either Code only, or Code + data. Restoring data replaces your Draft's current 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.

Each of these asks first, in a confirmation whose lines say what it changes before anything does — for a data restore, that The current rows are kept first. Restoring is safe: bringing back an earlier version never deletes your newer ones, and the data a restore replaces is kept as a version of its own, marked Before a restore, so you can restore that too.

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

Once your App is published, the copy icon beside the address on the Live card copies its link, ready to paste into a message, post, or email. The copy icon on the Draft card copies your private draft's address instead.

The Share section of the Live window gives you two more ways to get it in front of people:

• A QR 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. The download icon saves it as an image.
• An embed code — a snippet you can paste into another web page so your App appears right inside it, with a copy icon beside it. Before it will appear on that page, allow the page's website to embed your App.

Share appears once your App is live — publishing is the one prerequisite for sharing it.

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. The Share section says so: Embeds · Blocked unless the site is listed.

To let a specific website embed your App:

1. Open Manage › Publish, then the Live window, and find Share.
2. Type the website that will host your App — for example, example.com — in the field under the list of sites, and press the plus icon.
3. Repeat for each website that should be able to embed it.

Your App's own address is always on the list, marked with a lock. To remove another website, press its bin icon and confirm Remove site — that site Can no longer embed your App, and you can allow it again at any time.

Posting your App to Slop runs a frozen copy of it

Posting your App to the community's Slop feed is not the same as publishing it. The post makes a copy of your App that runs on its own community page, for everyone who opens it, exactly as it was the moment you posted it — an App of its own, apart from your Live App. Publishing your App again never changes the post, and the posted code can never be edited: posting the same App again within about five minutes, before anyone has engaged with it, replaces it, and that is the one correction there is.

When the artifact you pick in Post to Slop is an App, the panel asks What your posted App runs with:

• Display only — the page alone: no saved data, actions or AI. Free.
• Interactive — the default. Visitors save data in a shared space, run its actions with your keys, and pay for their own AI. Free while no one uses it.
• Upgraded — Interactive, on a database or server of its own, on your account. Tick Its own database, Its own server, or both. Its own database takes one of your account's database slots, covered by the same monthly add-on as your Apps' own databases — the panel shows how many you use and the price. Its own server starts when someone uses it and is metered like your Apps' servers; it's offered only for an App that runs a server. Both need a payment method on your account, and a post is refused before anything is copied when one is missing.

When your App has sign-in, the panel also shows Signing in on your post: each visitor signs in with one press, as a guest of their own. Guests join the groups ticked there — every group, until you untick one. A group your App sells says Sold in your App, free on the post, because a post takes no payments.

What a posted App runs with can only go up, never down — a service or a part, once given, stays. To open a Display only post to its visitors, open the post and choose Make interactive from its ⋯ menu — you'll see Visitors can now use your App. To give an Interactive or Upgraded post a database or server of its own, choose Upgrade… from the same menu, tick what it should run on, and select Save — you'll see Your posted App is upgrading; its data moves onto its own database and its server starts shortly after. Saving the same choice again tries again if an upgrade did not start. A replace inside the five-minute window can raise it too, never lower it. While a post is held for review its server stops and its data moves back to the shared space, and it takes both back when the post returns; unpublishing removes its database and server with it.

What a posted App uses: your keys, its own data

An Interactive post runs with what your Live App has, under rules of its own:

• Your keys, read-only. It uses the keys your Live App is granted — the same keys, never copies. Connections & Keys in your account settings lists the post among the Apps reading each key: a new value you give a key reaches the post too, and revoking the post's access there stops it using that key. A visitor never sees a key's value. A link to another App's list is not shared with the post: an action there that reads one is refused with the message that the variable is not linked to a list yet, exactly as in an App with no link. A Display only post holds no keys.
• Its own data. Its lists start empty and collect what its visitors save, on the post — never in your Live App, whose data it can't read.
• Visitors sign in as guests. If your App has sign-in, each visitor signs in on the post with one press, as a guest of their own: no email, no password, and only their own things are theirs. A guest account is deleted, with what it saved, 30 days after its last visit. It takes no payments.
• Each visitor pays for its AI. Its in-app AI answers as your assistant stood when you posted, and each visitor uses it signed in to MotherFluxer, paying for what they use. Your credits are never drawn.
• It counts as one of your Apps toward both App limits while it is up. Unpublishing the post takes its App away with it, together with what its visitors saved.

You find it in Artifacts as an App card of its own, with no menu. It opens on Manage, holding only its Data, Money and Health, and you can read them and export its data, but not change anything.

What a post or a copy of your App never carries

When your App leaves you — posted to Slop, saved by someone from a post, started as a co-op, or viewed through a share link — what goes is its code, its files and its settings. These always stay behind:

• Your brief — what you told the AI that builds your App, in Develop › About. Only the rows naming each feature it has installed go along.
• Your assistant's persona — how you told your App's assistant to act. A copy's assistant stays off until its new owner writes their own.
• Installed features' guides.
• Your reference documents and brief documents — the documents your assistant answers from and the ones you gave the AI that builds your App.
• Files and folders whose names start with a dot.
• Every key's value. A copy keeps the names its code reads, never what they hold.
• The record of how it was made — your prompts and the generation behind it.
• Your visitors' data and sign-ins, which belong to your own App.

A key typed straight into one of your files is redacted in the shared copy. Your own copies — saving it as new and its .zip download — keep everything. Your GitHub backup keeps its code and settings; its Assets files come with the .zip.

A saved copy of a posted App starts on Setup needed

Anyone who saves your post gets their own copy of your App: the same code, files and variables, not published, and with no keys set up — your keys never travel with it. Opening it takes them to Equip › Connect, where the Variables list leads with each key it needs marked Setup needed, and it can't go live until those are set. The same is true of a copy you save of someone else's App.