Recipes

These are complete deployments that you can follow from start to end. Each recipe takes one shape of project: a static site, an API, or a background worker. It then shows the full path. You create the app, write the files, set the environment, deploy, and check that the app is live. A coding agent can follow a recipe for you. The fastest method is to give your agent the recipe and say "do this".

If your agent has no connection to xhostd, start with Getting Started. Then come back here. An agent that works with no person at a browser opens its own account: Register as an agent.

Push code with git tells you about the credential, the remote URL and the git push command.

Operate your projects

Projects & channels — Project scope, channel isolation, and shared account capacity.
Deployments — Push a revision, review a deployment, and distinguish results from serving state.
Data & recovery — Postgres, files, recovery points, exports, and restore safeguards.
Access & security — Membership, credentials, protected agent actions, and app sign-in.
Troubleshooting — Find build, runtime, traffic, and resource evidence.

The recipes

The table lists the available guides. Each guide is complete in itself. You do not need to read the other guides first.

Guide	You get	Status
Static site	An HTML/CSS/JS site on an HTTPS URL	Ready
Node.js app	A JSON API on Express	Ready
Python app	A JSON API on FastAPI	Ready
Docker app	Any runtime, from your own Dockerfile	Ready
Postgres	A database, with migrations that run on deploy	Ready
File uploads	An app that stores files in object storage	Ready
Sign in with Google	An app that knows who its visitors are	Ready
Raw TCP	A public `host:port` for a service that is not HTTP	Ready
Background worker	A long-running process, not a web server	Ready
Ship without git	A site put onto the app by tool call, where there is no shell to run `git` in	Ready
Best practices	The habits that keep a deploy free of surprises	Ready
Diagnose a slow app	The cause of a slow or unhealthy channel, and the action for it	Ready
Client blocks a deploy	The way to clear a `deploy` call your own client refused before it reached xhostd	Ready
Custom domain	Your own domain, with HTTPS	Coming soon

The parts of a recipe

Every recipe has the same start point and the same end.

What you need first

You need an xhostd account, and an agent that can reach the xhostd tools. You need nothing more. There is no local runtime, no build step on your machine, and no server to rent.

What the transcripts show

Every tool call, every deploy log and every curl in a recipe is verbatim output. It comes from a real run on a real account: the docs demo account, whose apps stay up. Thus a hostname such as recipe-static-docs.randomimity.app is a live address that you can visit. It is not a form for you to complete. If you follow the recipe yourself, you get the same app under your own account name.

Where a recipe shortens a value, hides a value, or gives prose instead of a capture, it says so at that place. The credentials are always placeholders. One or two failure paths are in prose, because a real failure on a public demo leaves the demo in a bad configuration.

The Raw TCP recipe is different in one way. Its app is up on the demo account, the same as the other apps. The run then released the public host:port in its transcript, on purpose. That address therefore does not answer. It is the one captured address in these guides that you must not use. Each new exposure gets a new address.

How it ends

Every recipe ends with a live address, and the one command that proves the address works. For an HTTP recipe, that command is:

curl -sS https://<app>-<account>.randomimity.app/

If the command prints your app's response, the recipe worked. If it does not, the recipe tells you which check to run next.

Two recipes end in another way, because each one deploys a service that uses no HTTP. The Raw TCP recipe proves itself with a socket round trip to a host:port. The Background worker recipe has no address that answers, so it proves itself with get_runtime_log, which counts the work the worker did. The HTTPS hostname of each one returns 502 by design.

A recipe shows the correct path, and also the two or three usual faults. A recipe is not a reference. MCP Tools and the API Reference give the full lists of the tools and the endpoints.