# huta

> huta ships small projects to one server you own. An agent or person builds a container image on a dev box and asks for a release; the host verifies the commit (on `main`, and CI green when the target requires it), reads `deploy/app.toml` from git at that sha, checks the image's labels, user and platform, writes a plan, and waits for a human to approve. Then it starts the new release on an idle slot, checks that `/healthz` reports the sha, switches the vhost in one graceful reload, and stops the old slot after a short drain (long requests, streams and websockets can be cut). Status: v1. Available: one recipe `web` (exactly one HTTP container), with what the host's operator grants per target: secrets and settings as environment variables (a dev box can send a secret's value; it goes live with the next release the owner approves); outbound HTTPS through an allowlisting proxy by hostname, and named host services (upstreams), with no DNS or other route out; a data volume of a fixed size mounted at one path, with consistent backups shipped off the server; scheduled jobs in the live release's image, optionally also run after each release; smoke checks on the new slot before the switch and public checks after it, with an automatic switch back; adopting a live site's vhost at the first release. Two transports (pull: a dev box on the same host with a shared inbox; push: any dev box over an ssh forced command plus a registry on the host), approval by the owner with one tap (✅ Deploy / ❌ Reject buttons on the release's Telegram history message, single-use secrets) or with `huta approve` on the host's command line (the fallback), and a Telegram history message per release, edited as it moves. Planned, not available: several containers per project, Postgres and migrations, unattended releases, gateway/external recipes, `huta logs/diag/snapshot` for agents, monitoring hooks, plain-HTTP egress.

If you are an agent asked to **install the huta client** on a machine, follow https://huta.run/install.md step by step (it tells you what to ask the human and what to confirm before touching the server). If you are an agent asked to deploy a project with huta, read the start page first, check its prerequisites, then follow it in order. Everything is also in one file: https://huta.run/llms-full.md

This index is served as https://huta.run/llms.md; `/llms.txt` and `/llms-full.txt` are the same content under the llms.txt-convention names.

## Docs

- [Install the client](https://huta.run/install.md): for an agent asked to set up a dev box: what to ask, what to confirm, `huta enroll` on the server, `install-client.sh --settings`
- [Start here](https://huta.run/docs/start.md): prerequisites to check first, then the checklist: what to add to the repo, how to test, build and submit, what you cannot do, what to tell the human
- [Contract](https://huta.run/docs/contract.md): every `deploy/app.toml` key (`[state]`, `data`, `concurrent_safe`, `[[smoke]]`, `[[jobs]]`) and what huta refuses, the TOML top-level-keys pitfall, enforced image rules vs recommended patterns, `/healthz`, the host registry fields the operator fills in
- [Runtime](https://huta.run/docs/runtime.md): what the app gets at run time and how to write it: secrets and env, egress through `HTTPS_PROXY` (no DNS), upstreams, the data volume (one writer vs concurrent, per-slot files, backups), jobs, smoke checks and automatic revert, the headers the app receives (`CF-Connecting-IP`)
- [Moving a live site](https://huta.run/docs/moving.md): taking over a site that already runs on the server: what to move into the image, data import, secrets import, adopting the old vhost at the first release
- [Dockerfile patterns](https://huta.run/docs/dockerfile.md): copy-paste Dockerfiles for a tiny static site and a small HTTP service, and a local test
- [Commands](https://huta.run/docs/commands.md): `huta pack / submit / status / log / login`, `client.toml`, host commands, what each prints, release states and the three outcomes
- [Transports](https://huta.run/docs/transports.md): pull and push, setup for each (push: one host user `huta-<box>` per box), the request format, single-use request ids
- [Approval](https://huta.run/docs/approval.md): one-tap Deploy / Reject buttons in Telegram and the CLI fallback, the checks both run, what a plan shows, 30-minute expiry, notifications
- [Rules](https://huta.run/docs/rules.md): releases are commits on main, secrets only on the host (never in the repo or image; a box may send a value with `huta secret set`, staged until an approved release), scheduled jobs policy, debug access (status, log and jobs now, more planned), only the owner approves, when to ask a human
- [FAQ](https://huta.run/docs/faq.md): exact refusal messages and Telegram button replies, and what to do about each

## Optional

- [Everything in one file](https://huta.run/llms-full.md): this index and all pages above, concatenated (alias: `/llms-full.txt`)
- [Landing page](https://huta.run/): the human overview