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:

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 (a Dockerfile at the root, a server framework the CLI recognises, or --service) or a digest-pinned --image. The process must listen on port 8080, or on the port named with --port or "port" in tori.json. A Dockerfile or brought image must declare a numeric non-root USER; a detected source build is arranged that way for you.

What is available

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 only: new apps run in Prague (`cz-prg-1`). There is no US location, and the API refuses `us`
Managed Postgres	Preview; not generally available
MCP for coding agents	Preview; see MCP setup

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.

The sign-in page links the privacy policy, which says what Tori keeps about your account and for how long, and the terms of service.

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

GitHub, Google and Apple (not available yet)

Signing in with a GitHub, Google or Apple account is built but not switched on at api.tori.host yet. Until it is, the sign-in page offers the magic link only, and nothing below applies.

When it is on, the sign-in page shows Continue with GitHub, Continue with Google and Continue with Apple next to the email field, and the rules are these:

The provider signs you in to the Tori account that owns the same verified email address, and creates one if there is none. A magic-link account and a GitHub sign-in with that address are therefore one account. The first time that happens, the account’s address receives a mail saying which provider was connected, so a connection you did not make does not go unnoticed.
If the provider does not vouch for the address (for GitHub, your primary address is unverified), the sign-in is refused and says so. The magic link still works.
After the first sign-in, the provider account itself is what is recognised. Changing your email at the provider does not move you to another Tori account.
With Apple’s Hide my email, Apple gives Tori a relay address instead of yours, so a first Apple sign-in creates a new account. To use Apple with an account you already have, sign in by magic link and connect Apple under Settings → sign-in methods.
The CLI’s browser sign-in uses the same page, so either way into the console also signs in npx tori.host.
Settings → sign-in methods will connect a provider to the account you are signed in to, whatever address the provider has, and disconnect it again. Disconnecting a provider also ends the sessions it signed in, including the one you are using if it came from that provider; sessions from the magic link or another provider stay. The magic link keeps working either way, so disconnecting the last provider does not lock you out. Connecting one mails your account’s address as well, so a connection somebody else made from your account does not go unnoticed.

Signing in from another device

When the CLI opens a browser, it also prints a link for another device underneath. The link carries a short code:

→ opening your browser to sign in…
  Browser on another device? Open https://my.tori.host/cli-auth?user_code=PQXR-4K7M

If the browser opened on the machine in front of you, sign in there and the terminal continues on its own; the link is not needed. If it opened somewhere nobody is looking — a remote desktop, a terminal attached to another computer — open the link on any device where you are signed in to the console, check that the code matches, and click Approve. The same running command continues. You do not need to restart it. Whichever finishes first signs you in, and the other is abandoned; approving both still saves only one token.

The link approves nothing by itself. The console shows the name of the machine asking and the code, and waits for you to click Approve. Only approve a code that your own terminal printed; a link someone sends you signs in their machine to your account.

On a machine with no browser

Over SSH, in a container, or anywhere with no DISPLAY, the CLI does not try to open anything. It prints only the link and the code:

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

Open the link on a signed-in device, or go to https://my.tori.host/cli-auth and type the code there (on a phone, for instance).

--no-browser does the same 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.

In CI

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:

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

For a pipeline, choose Deploy one app when you mint it: a deploy token (torid_…) deploys the app in tori.json and reads its deploys, and cannot delete anything or reach another app. What it deploys still runs with that app’s secrets, so guard it like them. A token for the Whole account (tori_…) can do anything your account can. Deploy from CI has GitHub Actions and GitLab CI workflows.

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

Console

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 new apps run in, and API tokens. The region is shown, not chosen: EU · Prague (cz-prg-1) is the only location, and an app stays where it was created.

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

Quickstart — first static deploy
Deploy a static site — packing, CI, and failures
Deploy a container service — digest-pinned images
Environment variables
Logs
Deploy status and recovery
Plans and billing — not generally available yet
Disabled apps and accounts — when Tori disables an app or an account
CLI — commands
API — HTTP
MCP — connect a coding agent and understand tool safety

The CLI serves the MCP interface over stdio. See tori mcp for the command reference and the generated tool catalogue for the exact registry advertised by this version.

Download this page as Markdown.