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:

1. on the website host, or
2. 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:

1. an active platform subscription;
2. 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.

My new file is not showing

First check that the publish finished and the site serves the new release: open the page in a private window. HTML is never cached at the edge, so a new index.html shows on the next load.

If one file is still old:

• A file without a hash in its name (images/logo.png, assets/react.js) can stay in a browser for up to 5 minutes. Reload hard, or wait.
• A file with a hash in its name (assets/index-Bm4e1gYd.js) is cached for a year. If you published different bytes under the same name, the edge copy is cleared for you, but a browser that already downloaded it keeps its copy. Rebuild so the file gets a new name, then publish.
• A query string does not help. app.js?v=2 is the same cache entry as app.js. Change the file name instead.

See Caching for a static release for which names count as hashed.

My Cache-Control header is ignored

That is expected. For a published zip release, the site host sets Cache-Control on every response and replaces any value your files carry. Hashed files get public, max-age=31536000, immutable, HTML gets no-cache, other files get private, max-age=300, and errors get no-store. You cannot change these today.

To have a file cached at the edge, give it a content-hashed name inside a folder, as Vite does by default. See Caching for a static release.

Related

• App Host
• Website and process
• Buzz
• Files
• App Data
• App Data
• App Data Query
• Signing keys
• App Enablement