Publish your app
Review what is missing, choose a store or host, and publish Android, iOS, desktop or web from one sheet.
On this page
What Publish does
Publish is a review-first sheet for the current workspace. Opening it checks your saved settings automatically and shows only the requirements that are still missing. Nothing is uploaded until you press Publish.
It is separate from a local preview. Publishing sends a build to a store or a hosting provider. The older self-hosted path through Dokploy is no longer in the product UI; self-hosting with Dokploy records what it was and what to use instead.
The sheet never uploads on its own. Every send to a store happens after you confirm the review.
the sheet opens for your project and shows a short list of what is still missing.
Destinations and what each one needs
| Destination | What the host needs |
|---|---|
| Android store | An app ID, a store credential, the upload tool, Android build tools and release signing. |
| iOS App Store | A Mac with Xcode, the App Store Connect key and fastlane. A non-Mac host reports that a Mac is required. |
| Desktop | The project’s electron-builder configuration and its destination credentials, plus build targets, signing and notarization choices. |
| Web host | A supported provider (Vercel, Netlify, Railway or Replit), the provider CLI and a saved token. Replit stays guided because it has no deploy command. |
| Custom | A publish script declared by the project. Lyre lists the allowed scripts and runs the one you choose. |
The review names the destination the project declares. When a readable configuration declares no upload destination, upload stays disabled and the default is installers only.
one destination is named and its requirements list is either empty or understood.
3 · Fill the missing requirements
Most gaps are values you can type straight into the sheet.
-
Save the missing values
An app ID or a store key can be saved directly in the sheet. Invalid input is explained before anything is saved.
-
Install an upload tool only when you choose to
This follows the recipe the host advertises. It is never done silently.
-
Paste a web token once
It is stored under
.lyre/store/on the host. It stays in memory until you save, and it is not kept in your remembered preferences. -
Read the desktop signing result
A desktop build that skips signing is marked Unsigned, and the acknowledgment says whether the installers are unsigned or the host found no signing credentials.
the sheet no longer lists a missing requirement for that destination.
4 · Review, then publish
The sheet moves through Setup, Review and Publish. The review shows the project, the current version, how the version will bump, the source and the release effect.
-
Confirm destination and source
The source is usually the current workspace. Check it is the one you mean.
-
For Android, choose a track
Internal, Closed (alpha), Open (beta) or Production. Then either save a draft or submit the release. Internal draft is the default.
-
For production, acknowledge the audience
Confirm the full-audience release before submitting.
-
Publish and watch the real operation
Lyre shows the pending operation. It does not invent upload percentages.
On success, Android points you to Google Play Console, and a web publish reports the URL the provider’s command printed. Store listing, screenshots and audience still belong to the store’s own console.
the operation finishes and the sheet reports where to watch it next.
If a publish result is uncertain
A lost response is reported as unknown, not as success. Check the destination, the store console or the host’s web provider, before retrying.
Closing the sheet does not cancel a host operation, and reloading the app cannot recover a running host job, because the current protocol has no job-status or resume endpoint.
See when something does not work for connection and provider problems.
the destination tells you whether the release exists, not the sheet alone.
What publishing does not do
Lyre prepares and runs the publish. It does not guarantee store review, availability or a public URL. A returned web URL is reported as printed and is not verified by the host.
Treat a successful command as completion of the command, not as proof the release is live. Store submission, public publication and installed-device acceptance each have their own gates. Follow release status rather than assuming a listed destination is ready on your platform.
you have opened the published result yourself from the destination, not from the publish sheet.