Publishing and Sharing Your App – Caffeine AI

Building an app is one thing. Getting it in front of people is another. Until your app is published and shared, it only exists for you. Publishing is the moment it becomes real — accessible at a permanent URL, ready for real users, with data that persists. It is also the point where your decisions start to have consequences: changes that reach live users immediately, rather than sitting safely in a private draft.

Every Caffeine app has two versions: a draft and a live version. You build and test in draft, then publish to live when your changes are ready. Your live app gets its own URL that you can share with anyone.

Draft and live mode

Draft is your working environment. Every change the AI makes goes here first. The draft runs at a separate URL from your live app, so you can test new features without affecting your real users. Draft data is temporary — it may be reclaimed if the draft has been idle for a while, and drafts that expire are automatically restored the next time you open the project, as long as there is a previously deployed version to restore from.

Live is your production app — the permanent version your users access. Live data persists as long as your subscription is active. Only you can see the draft; your users only ever see the live version.

Version history

The version history panel shows every build of your app. Each entry is labelled with a version number and the time it was built. Two badges identify key versions at a glance:

Current — the version your draft is currently running.
Live — the version deployed to your live app.

If Current and Live point to different versions, it means you have built new changes in draft that have not yet been pushed to live.

When a draft is starting up — whether after a new build or an automatic restore — a loading bar appears at the bottom of the preview panel label. The preview becomes interactive once the bar reaches 100% and disappears.

Going live

When you are happy with your draft, click the Go live button in the chat panel. Caffeine handles the deployment automatically, including any necessary data migration. The process takes a moment, then your live app is updated. The button shows "Going live…" while the deployment is in progress.

Always review your draft thoroughly before going live. Your real users see changes immediately once they are published.

Once your app has a live version, the button in the chat header changes from Go live to Live. Clicking it opens a dropdown menu with quick actions:

Open live app — opens your live app in a new browser tab. The current live version number is shown alongside the option.
Copy app link — copies your live app's URL to the clipboard so you can paste and share it anywhere.
Push version update — appears when you have built new changes in draft that have not yet been published to live. Click it to deploy those changes directly from the header without opening project settings. The pending version number is shown alongside the option. While a deployment is in progress this item is replaced by Pushing version update and cannot be clicked.
Go live — appears when your app is in an unpublished state. Clicking it runs the standard Go live flow and brings your app back online.

The Live Apps button

On desktop, a Live Apps button appears in the chat header between the Go live button and your account avatar. Clicking it opens a menu listing your live apps, giving you quick access to any live app without leaving your current project.

Your live app has a permanent URL that you can share with anyone. The quickest way to copy it is to open the Live dropdown in the chat header and choose Copy app link. You can also open project settings (gear icon) → More → Copy share link. No login is required to view a live app unless your app enforces authentication.

Draft apps also have URLs, but these are not intended for sharing with end users — draft performance and availability is not guaranteed.

What's happening behind the scenes

Every Caffeine app runs inside canisters on the Internet Computer — one for the frontend and one for the backend. Draft and live each have their own canisters, and they behave differently:

Draft canisters are temporary. They are assigned to your project from a shared pool while you are actively editing and testing. As long as you keep sending messages, the draft canister stays assigned to your project. After about two hours of inactivity, the canister expires and returns to the pool. If your project has a previously deployed version, it is automatically restored the next time you open the project. If a draft canister runs out of resources, it is simply replaced on your next build.
Live canisters are permanent. They are created when you first publish your app and persist for as long as your app is live. They hold your production data and serve your real users. Live canisters have automatic resource monitoring that keeps them running without intervention.

You do not need to manage canisters directly — this is handled entirely by Caffeine. This section is here to help you understand why drafts can expire and why live apps behave differently.

Frequently asked questions

What happens if my draft expires?

Drafts that have been inactive for a while may be reclaimed by the platform.

If your project has a previously deployed version, Caffeine automatically restores the draft the next time you open the project. During startup, the preview panel shows a loading indicator while the draft is restored.

If there is no previously deployed version to restore from, the preview panel shows a message prompting you to rebuild.

In some cases the preview may show “App is sleeping” with a Wake up button. Clicking it restores the draft from its last saved state.

No code is ever lost.

Can I roll back a live update?

There is no rollback for live deployments. If you push to live and something goes wrong, fix it in draft first — revert to an earlier draft version using the Revert to version N button on any past build in your chat history, or open the version history panel by clicking the version badge in the top-right corner of the app preview panel. Then go live again with the corrected version. Note that you cannot revert to a version older than the one that is currently live — this protects your live users' data.

How do I prevent mistakes from reaching production?

Test everything in draft before going live. The draft URL lets you use your app exactly as a real user would. Only push to live when you are confident the changes are correct. You can also set the AI to Guided mode to reduce the chance of the AI building the wrong thing — it asks clarifying questions before starting.

Does going live affect my users' data?

Caffeine handles data migration automatically when you publish. The Motoko framework checks whether the update is safe before applying it — if the change could cause data loss, it is rejected and the AI rewrites it. Your users' data is protected.

Can I have a custom domain instead of the default URL?

Yes, on Plus or Pro plans. See the Custom Domains section for how to purchase and connect a domain.

Copy the draft URL from your browser and share it directly. Anyone with the link can view the draft, but the URL is not publicly indexed or discoverable.

Why does my custom domain still show an older version after I changed my draft?

Custom domains always serve your live app, not your draft preview. If you built new versions in draft but did not push them live, the custom domain will keep showing the older live version.

Check your version history:

Current = the draft version you are editing now
Live = the version users see on your public URL and custom domain

If these badges point to different versions, push the latest draft with Go live (or Push version update in the Live dropdown). After publishing, wait about a minute and reload in an incognito/private window.

My app won't deploy — what's causing it and what should I do?

The most common cause of a failed deployment is a backend migration conflict. Caffeine apps store data on the Internet Computer, and every time you deploy a new version, the system checks whether the new backend is compatible with the data structure of the previous version. If recent changes introduced a breaking incompatibility — a field removed, a type changed, a data structure restructured in a way the migrator cannot reconcile — the deployment is rejected to protect your existing data.

You have four options for getting unstuck:

Revert your draft to a working version. Identify a past build that deployed successfully — typically the version before the breaking change was introduced — and click Revert to version N on that build in your chat history. Then re-prompt the AI to introduce the change you wanted in a different way that does not break compatibility. This is usually the fastest path. Attempting to patch your way forward through more prompting can compound the problem — go back to a working baseline first.
Download the source and fix it manually. Open project settings → More → Download files to get the full source. You can then resolve the migration conflict in your own editor and redeploy. This path is currently more involved; the upcoming Caffeine CLI (under development, not yet available) will make deploying directly from the command line straightforward, including showing the underlying migration error.
Take the app offline and publish a fresh live version. If you are willing to permanently lose all live data, you can break out of the upgrade cycle entirely. Open project settings → More → Take offline and confirm. This tears down your live canisters completely. Once the app is offline, click Go live to publish your current draft as a brand-new installation — because there is no existing live canister to upgrade, the schema compatibility check is bypassed and your draft is installed clean. Use this path when you cannot fix the migration conflict another way and are prepared to start with no live data. It cannot be undone.
Remix the project from a chosen version. Open the version history panel and click Remix this version on the version you want to start fresh from. This creates a brand-new independent project with the chosen version's code and a clean canister — no accumulated memory layout from earlier versions. The downside is that the new project is independent: it gets its own live URL and starts with no data and no chat history. If you want to carry context across, ask the AI in the original project for a chat summary you can paste into the new one. See Editing and Managing Your App for full details on remixing.

Note that Reset app data does not solve a migration conflict. It redeploys the version that is already live, with its data wiped — the version that does not deploy is still in your draft, and the underlying schema mismatch with what is installed on the live canister remains. See the next FAQ for what Reset app data is actually for.

What does "Take offline" do?

Take offline permanently destroys your live app's infrastructure — live canisters are archived, analytics removed, and all live infrastructure torn down. This action cannot be undone. Publishing again will provision entirely new live infrastructure from your current draft — because new canisters are provisioned, the next Go live is treated as a fresh installation rather than an upgrade, which also means any schema compatibility check is bypassed. On-chain data and live-only state from the previous deployment cannot be restored. If your project has a user-owned custom domain (bring-your-own domain), taking the app offline also starts full deregistration for that domain in Caffeine — the domain record and related setup (including email identity where applicable) can be removed, and you would need to add and configure the domain again before using it on a new live deployment. To take an app offline, open project settings → More → Take offline, and type "remove" in the confirmation dialog to confirm.

What is Reset app data and when should I use it?

Reset app data redeploys your currently live version to your live canister and permanently erases all data stored in it. The live version's code is reinstalled fresh — your draft is not touched, and no new code is pushed live. Any data your users have created will be gone and cannot be recovered.

The typical use case is cleaning up before a real launch. During development you might go live several times, accumulating test users, test posts, sample records, and other throwaway data on your live app. When you are ready to start announcing your app and inviting real users, Reset app data lets you wipe that test data in one step without changing the deployed code.

To reset app data, open project settings, select More, and choose Reset app data. A confirmation dialog explains what will be deleted before you proceed.

Reset app data is not the right tool if you are blocked by a migration conflict between draft and live. See the previous FAQ for the recovery options that apply in that case.