Skip to content

Getting started

Tori hosts static sites and container services. Customer apps answer at https://<slug>.tori.cloud. You deploy with the CLI; nothing else has to be installed:

Terminal window
npx tori.host

That command is tori deploy for the current directory. Node.js 20 or newer is required (npx ships with it). An app is one of the two kinds when it is created, and that choice cannot be changed later.

  • A static site is files served from object storage. Nothing runs, so nothing reads environment variables.
  • A service is a container the zone runs for you. Deploy from source (--service, or a Dockerfile at the root) or a digest-pinned --image. The process must listen on port 8080. A Dockerfile or brought image must declare a numeric non-root USER; a detected source build is arranged that way for you.
Capability Launch status
Static sites on *.tori.cloud Available
Container services (source build or digest-pinned image) Available
Sign-in (browser, device code, CI token) Available
Environment variables on services Available; applied on the next deploy
Application logs Available when the zone is collecting them
Custom hostnames Available if the plan includes them
Regions EU · Prague. There is no US zone yet
Managed Postgres Not generally available
MCP product setup Not a documented product guide yet; the CLI still lists tori mcp

tori whoami prints the signed-in email and plan name. The console (https://my.tori.host) shows the same plan under Settings. A request that exceeds the plan is refused and names the limit — do not treat marketing copy as the cap.

Idle services scale to zero. The first request after a nap wakes the revision; there is no always-on replica on any current plan. There is no usage meter or overage invoice today. Database storage, egress, and build minutes are not sold as separate products.

There is nothing to set up first. Run the deploy. If this machine has never signed in, a browser opens, you sign in (or sign up — they are the same click; auth is a magic link to your email), and the deploy continues.

What gets saved to ~/.config/tori/config.json is an API token named after this machine (CLI · <hostname>). It appears in the console under Settings → API tokens. Revoking it there stops this machine deploying, immediately and by itself.

npx tori.host login signs in without deploying. npx tori.host whoami shows the account. See tori login for flags.

Over SSH, in a container, or anywhere with no DISPLAY, the CLI does not try to open anything. It prints a short code and a URL instead. Open the URL on a signed-in device, type the code, and the terminal continues:

Open: https://my.tori.host/cli-auth
Code: PQXR-4K7M

--no-browser selects that flow on a machine that does have a browser. BROWSER=none does the same through the environment.

Approval is an explicit click in the console. A crafted link is not enough on its own.

There is nobody there to approve a sign-in, so the CLI does not try. Mint a token in the console (Settings → API tokens), copy the secret (shown once), and set:

Terminal window
export TORI_TOKEN=tori_
# optional; this is the default
export TORI_API_URL=https://api.tori.host
npx tori.host deploy ./dist

Revoke that token in the same Settings list when the pipeline should stop. TORI_TOKEN overrides the config file.

The console is https://my.tori.host. After a magic-link sign-in it lists your apps. Each app has overview, deploys, domains, env, and logs. Settings holds the plan, the region toggle (leave EU until a US zone exists), and API tokens.

Deleting an app in the console stops it serving immediately. The slug stays yours; nobody else can take the old URL.

The CLI can serve tools over stdio; see tori mcp. Product MCP documentation (connection, authentication, tools) ships with that interface, not as a separate sidebar section.

Download this page as Markdown.