App Host

Website and process

Publish a static frontend to the site host, or launch a container on a Machine. Buzz is neither of those.

The site host https://<slug>.app.orkestia.dev is your website. You can put a static frontend there, a container process, or both over time. Buzz is a different hostname and a different field manager (apphost-addon-buzz). Launching a process (apphost.web.deploy) pins the Deployment to the shared App Host pool and serves the website host. It does not take over the Buzz Ingress.

Choose a path

You have	What to do	Tab
A production frontend build (`dist/` with `index.html` at the root)	Publish a versioned zip	CLI, then Releases
A container image (`registry/name:tag`)	Launch the process	Launch
A public GitHub repository with a Dockerfile	Launch from the repo	Launch
Agents or clients that need a live websocket	Set up Buzz	Buzz

Cloud Deploy (GitHub → your AWS S3/CloudFront) is a different product. App Host's website host is Orkestia-managed. See Cloud Deploy if you are deploying into your AWS account.

Publish a static release

From the app project (after Identity and the production build agree):

orkestia apphost publish
orkestia apphost publish --yes

Without --yes, you see the plan. With --yes, the CLI packages dist/, uploads it, and points the site host at that release.

In the console, the Releases tab lists zip releases. Rollback is a release action. Image launch and Buzz are not zip releases.

The CLI that packages dist/ is documented with DevKit. Identity production checks live under App Enablement.

Launch a process

On the site, open Launch.

From an image (apphost.web.deploy)

Enter the container image, port, replicas, and size (small, medium, or large).
Start the launch. The console follows prepare and apply.
Attach Postgres if the process needs the app database. Postgres stays App Data — the process gets DATABASE_URL, not a sidecar Postgres.

From a GitHub repository

Enter the repository URL, git ref, context directory, Dockerfile path, port, replicas, and size.
Start the launch. The console follows inspect → build → prepare → apply.

A launch claims a Machine on the shared App Host pool. You do not bring a kubeconfig.

Machine

The Machine tile is capacity for the site:

You see	Meaning
Not allocated	Nothing on the pool yet. Launch or Buzz will claim one.
Allocated, sleepable	A process can run; it may sleep when idle.
Allocated, always-on	Required for Buzz. Setup upgrades the Machine in place.

You do not pick a node pool. Size is the shared class you chose on launch or Buzz apply.

What stays on which host

https://<slug>.app.orkestia.dev
  → zip frontend and/or launched process  (Space / static site)

https://buzz-<slug>.orkestia.dev
  → Buzz Nostr relay + /media (site MinIO PVC)

Your own API host (not an AppHost addon)
  → DPWAI Chat Relay REST/SSE and similar product APIs

Do not expect /_readiness on the website host to return the Buzz JSON. That check belongs on the Buzz host. Do not reuse product sites as a client Buzz. Chat attachments for dbhost Apps stay on the Buzz MinIO PVC — not CloudFront, not data.appdata.document.*. Org-member Files use the same PVC under files/.

Your app and site
Buzz
Files
Cloud Deploy — deploy a static app into your own AWS account

App Data

The app's Postgres — tables and records in the console, SQL in Query, process login attached from App Host.

Buzz