App lifecycle

This page covers the full lifecycle of a Stayblox app: choosing a distribution, pushing versions, releasing (and rolling back), and the review pipeline for public apps.

Distribution: private or public

Set distribution in app.toml before your first push. You cannot change distribution after an app is created.

Distribution	Who can install it	Review required	Store listing
private	Teams in your account only	No	No
public	Any host, through the App Store	Yes	Yes (Dashboard)

Use private for internal automations and custom integrations where you control every installation. Use public when you want to distribute your app to other hosts.

Push: immutable versions

Every stayblox app push creates a new immutable version of your app. The config you pushed is frozen at that point; future pushes create new versions rather than overwriting the current one.

stayblox app push              # push + release (default)
stayblox app push --no-release # push without releasing

View all versions:

stayblox app versions

Release and rollback

The live version is the config active installs run against. By default, app push releases the new version immediately. You can decouple the two steps:

stayblox app push --no-release   # snapshot a new version, keep current live
stayblox app release             # promote the latest pending version to live
stayblox app release 3           # promote a specific version number (rollback)

Rolling back with release 3 re-releases an older approved version. The version itself is immutable; re-releasing it just makes it live again.

Review: private apps

Private apps skip the review pipeline entirely. Every push takes effect immediately; app push creates and releases the version in one step.

Review: public apps

Public apps go through a per-dimension review. Config and listing are reviewed separately and can roll back independently.

Config review

A config change (a new push) is applied automatically in most cases. Two situations trigger an admin review before the version goes live:

• First publish: the very first version of a public app is reviewed before going live.
• Scope escalation: adding scopes that were not in the previously approved version.

Automated checks run immediately on every push:

Check	Detail
Manifest schema	All fields pass structural validation.
Known scopes	Every scopes entry is a known value.
Known webhook topics	Every topic is known, and its required scope is listed.
All URLs https://	No http:// or insecure URLs.
Injection templates	Pass the sanitizer; no inline scripts, only trusted https:// origins.

Automated check failures block a version from going live but do not prevent a new push.

Listing and icon review

The store listing (description, gallery, pricing, and category) and the app icon are managed in the Account-panel Dashboard, not in app.toml. Every listing change goes through a content review before the updated store page goes live. Your currently approved listing keeps serving until the new one is approved.

This review is independent of the config review, so you can ship a config fix without waiting for a listing review, and vice versa.

Scope escalation for existing installs

When a new public version escalates scopes:

• The new config goes live after approval.
• Existing installs keep running on their previous granted_scopes.
• A "Requests new permissions" banner appears on the install settings page for each affected host.
• API calls and webhook deliveries that require the new scope are denied until the host consents.

Your app must handle scope-denied responses gracefully.

Getting listed in the App Store

A public app appears in the App Store once:

1. At least one config version has been approved.
2. The store listing in the Dashboard is complete and approved.
3. Your partner account is in good standing.

Draft apps and apps pending their first review are not listed.

Checklist

• [ ] distribution set correctly in app.toml before the first push.
• [ ] Config pushed and version released (stayblox app push).
• [ ] App installed on a team; API calls, webhooks, and any optional surfaces (app page, OAuth) tested.
• [ ] For public apps: store listing completed in the Dashboard (description, gallery, pricing, category).
• [ ] For public apps: first-publish review approved.