Troubleshooting App Host
Start by naming which hostname you opened. Most confusion is the website and Buzz sharing a mental slot they do not share on the network.
I opened the site and it is not Buzz
https://<slug>.app.orkestia.dev is the website. A zip release or a launched process answers there.
Buzz answers on https://buzz-<slug>.orkestia.dev.
If /_readiness on the website returns HTML, that is expected. Check readiness on the Buzz host.
Readiness is HTML, not {"status":"ready"}
You are either:
- on the website host, or
- on the Buzz hostname before the relay owns it.
On the Buzz tab, public Open links stay closed until the host is the cluster. Wait for setup to finish, or use Restart if a part is degraded. Then reload https://buzz-<slug>.orkestia.dev/_readiness.
Set up Buzz did nothing visible
Watch the stages on the Buzz tile (See stages). Setup has several steps (App Data, apply, host). The tile is not a row of secret buttons — Relay / Redis / MinIO are status, not clicks.
Size changes do nothing until Re-apply.
If the tile says Unavailable or workflow not found, live pod status is not on this runner yet. Re-apply still works. The chip falls back to the Machine being always-on. The Connect recipe (relay / readiness / media) is still the URL you give clients.
Claim failed / not claimed
apphost.site.claim needs:
- an active platform subscription;
- an Identity app that is provisioned and not
mode=dev.
Graduate the app with identity.app.set-mode (live) and https redirect URIs, then claim again. A localhost-only app cannot back https://<slug>.app.orkestia.dev.
Clients cannot AUTH
Buzz requires AUTH. Use NIP-42. Owner-backed agents use NIP-OA. There is no console field for a relay private key — that key never leaves the cluster.
Create or import nsec under Signing Keys, bind the site as owner, re-apply Buzz, then paste that same nsec into Desktop (Use a different key). A key Desktop generated itself will not match.
If you were given a wss:// URL on the website host, use the Buzz host instead.
Files tab is empty or says MinIO is not ready
Files need a claimed site and Buzz applied so MinIO is running. Claim and apply from the Identity app Hosting tab. Files are not App Data documents and not storage.*.
Removing Buzz deletes the MinIO volume, which also deletes those files.
I thought Buzz was Chat Relay
It is not. Buzz is Nostr. Product conversations for signed-in users belong in App Data (tables, ordered append, expose). See Buzz.
Process or Buzz cannot see tables
Attach Postgres on the site (Postgres tab). Browse structure in App Data. Run admitted SQL in Query.
A Query read-only login is not the process login. Re-attach if the process was launched before the instance existed. Apps still on the shared plane need instance provision before a direct login will exist.
I need a second slug for Buzz
You do not. Buzz is an addon on the same claimed site. A second slug is a different app.
Custom domain certificate fails for Buzz
Confirm the CNAME target is buzz-<slug>.orkestia.dev (one label of addon + slug, then orkestia.dev). Enter that customer hostname on the Buzz tab and Re-apply so the relay certificate includes your name.
Launch failed
Confirm the image exists and the port matches the process. For a GitHub launch, confirm the Dockerfile path and that the repository is public (or reachable with your GitHub connection). The Machine tile should move to allocated after a successful launch.