npx @tuqo/cli · nothing to install · Node 18+

Deploy from the terminal and from CI

One command publishes your build folder. Files go up one by one by hash, so a redeploy does not push the photos again, and in CI all you need is a secret with the key and one line.

TUQO_API_KEY=tqk_… npx @tuqo/cli deploy ./dist --site <site_id> --wait

Get a key Package on npm →

Commands

deploy <dir>: upload a folder by manifest: prints the deploy_id to stdout, and with --wait the live URL on a second line
deploy: with no arguments: every site from tuqo.json in one command, one line per site
preview <deploy_id>: secret link to a build made with --no-activate (from the Start plan)
promote <deploy_id>: publish the build and print the live URL (the deploy_id if the server returns no URL); the same command rolls back to an earlier version

Flags

--site <id>: site_id from the panel, whoami or create_site; or a folder mapping in tuqo.json
--wait: wait for the publish and print the live URL; exits with code 1 if the build fails, which is handy in CI
--no-activate: build without publishing: the live address does not change, and the version waits for preview / promote
--key <tqk_…>: project key; better use the TUQO_API_KEY variable (alias TUQO_KEY) so the key stays out of your shell history
--config <file>: path to tuqo.json (default ./tuqo.json)
--api <url>: API base URL, default https://api.tuqo.ru
--lang en|ru: message language; by default TUQO_LANG, then the terminal or system locale (see below)

stdout is machine-readable: the deploy_id, and with --wait the live URL on a second line. Logs and progress go to stderr, so you can capture the output in scripts.

Messages are in English or Russian. The language comes from the first of these that is set: --lang en|ru, TUQO_LANG, LC_ALL / LC_MESSAGES / LANG (C and POSIX don't count), then the system locale, which is what Windows relies on: Russian if it starts with ru, English otherwise. The stdout values are the same in any language.

CI recipes

The key goes in your CI secrets, the site ID in variables. The build stays yours: Tuqo receives the finished folder.

GitHub Actions

name: Deploy to Tuqo
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci && npm run build
      - run: npx @tuqo/cli deploy ./dist --site ${{ vars.TUQO_SITE_ID }} --wait
        env:
          TUQO_API_KEY: ${{ secrets.TUQO_API_KEY }}

GitLab CI

deploy:
  image: node:20
  stage: deploy
  only: [main]
  script:
    - npm ci && npm run build
    - npx @tuqo/cli deploy ./dist --site "$TUQO_SITE_ID" --wait
  # TUQO_API_KEY and TUQO_SITE_ID go in Settings → CI/CD → Variables (mask the key)

Repository on GitHub, GitLab, Gitea, GitVerse or GitFlic and no CI of your own? Use Git CD instead: Tuqo builds and publishes on every push.

Show a version before publishing

A build made with --no-activate does not go to the live address: visitors keep seeing the current version, and the client gets a secret link. Once approved, publish with one command. The same command rolls back to any kept version.

D=$(npx @tuqo/cli deploy ./dist --site <site_id> --no-activate --wait)
npx @tuqo/cli preview "$D"    # secret link for the client
npx @tuqo/cli promote "$D"    # publish once approved

Several sites from one repository

Locales, brands, campaign landing pages: put tuqo.json at the root and deploy them all with npx @tuqo/cli deploy and no arguments. The file is committed to the repository, so it must not hold a key, and the CLI checks for that.

{ "sites": { "site/en": "<site_id_en>", "site/ru": "<site_id_ru>" } }

sha256 dedup: files that match between deploys are never uploaded again
Bytes are read from disk, not through the model's context: made for Claude Code and Cursor
Up to 2,000 files, up to 50 MB per file, total within your plan's quota
The same publish checks as in the panel

CLI — frequently asked questions

How is the CLI different from uploading an archive? +

An archive goes up whole, even if one line changed. The CLI first asks the server which files it does not have yet, by sha256, and uploads only those: a text edit leaves the photos alone, and redeploying the same site is almost instant. There is no request body size limit, because files go up one by one.

Do I need to install anything? +

No. npx @tuqo/cli downloads the package on first run. You need Node.js 18 or newer. The package has no dependencies.

How does it work with AI agents? +

Claude Code, Cursor and other agents with terminal access call the same command. The bytes are read from disk and never pass through the model's context, so a heavy site full of photos is published without spending tokens on base64. In a browser chat with no file system, the agent publishes over MCP; the CLI is for places where there is a disk.

Where do I get a key? +

Panel → project → API keys → create a key with the editor scope (enough for deploys) or full. The key is shown once. For CI, store it in the repository secrets, not in tuqo.json: the CLI refuses to run if it finds a key in the config.

How do I show a version to a client before publishing? +

deploy --no-activate --wait returns a deploy_id, preview <id> gives a secret link, promote <id> publishes it. The link opens without a password even if the site is gated, so share it only with people you trust. Available from the Start plan.

What are the limits? +

Up to 2,000 files and up to 50 MB per file; the total must fit your plan's storage quota. The folder needs index.html at its root. What Tuqo checks on every publish is described on the Publish checks page.

My repository is on GitHub, GitLab or GitFlic. Do I need the CLI? +

Not necessarily. Connect Git CD in the panel and Tuqo builds and publishes the site on every push by itself. The CLI is for when the build runs in your own CI or on your machine.

One command, and the site is live

The CLI is a thin wrapper over the public REST API for manifest deploys: you can build the same thing in any language.

Start free REST API for uploads →