Website and process
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.
Caching for a static release
A published zip release is served through Orkestia's edge network. The site host sets the Cache-Control header on every response itself. A Cache-Control you set on your own files is ignored, and you cannot change these headers today.
| Response | Cache-Control | Where it is kept |
|---|---|---|
A content-hashed file, such as assets/index-Bm4e1gYd.js | public, max-age=31536000, immutable | At the edge and in the browser, for up to a year. Text files are compressed (Brotli or gzip). |
index.html, any other HTML, and app routes with no file extension that fall back to index.html (such as /settings) | no-cache | Never at the edge. The browser checks again on every load. |
Any other file, such as assets/react.js or images/logo.png | private, max-age=300 | In the browser only, for up to 5 minutes. Never at the edge. |
| Errors, redirects and suspended sites | no-store | Nowhere. |
What counts as a hashed file
A file is treated as hashed when:
- it is inside a folder (a file at the root, such as
/main-Bm4e1gYd.js, is not); - the end of its name, after a
-or.and before the extension, is at least 8 letters, digits,_or-; - that part has at least one digit or capital letter.
assets/index-Bm4e1gYd.js, assets/index-Bm4e1gYd.css and static/js/main.8f3a2c1b.js count. assets/react.js and favicon.ico do not.
Vite hashes file names this way by default, and so do most bundlers. Use a bundler that hashes file names to get edge caching and compression for your scripts and styles.
What this means when you publish
- A publish or rollback shows on the next page load. HTML is never held at the edge, so there is nothing to clear. You do not need to purge anything.
- Each hostname has its own cache. Your
<slug>.app.orkestia.devaddress and your own domain are cached separately, so the first visit to each one fetches the file once. - Query strings are ignored for caching.
app.js?v=2is the same cache entry asapp.js. To ship new content, ship a new file name. - Do not change the bytes behind a hashed name. If you publish different bytes under a hashed name that is already live, the platform detects it and clears that file from the edge automatically. Browsers that already downloaded it can keep the old copy for up to a year. Let your bundler pick a new name instead.
- A name that only looks hashed is treated as hashed. In
images/Team-Photograph.png, the part after the-is 10 characters with a capital letter, so the file is cached for a year. When you replace a file like this, rename it.
Launch a process
On the site, open Launch.
From an image (apphost.web.deploy)
- Enter the container image, port, replicas, and size (
small,medium, orlarge). - 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)
→ your product APIs (REST, SSE)
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 stay on the Buzz MinIO volume — not on the website host, not in data.appdata.document.*. Org-member Files use the same volume under files/.
Related
- Your app and site
- Buzz
- Files
- Static egress IP — a fixed outbound IP for vendors that allowlist addresses
- Troubleshooting — a new file is not showing
- Pricing and limits — see what your sites use
- Cloud Deploy — deploy a static app into your own AWS account