Control TryCase environments from the command line.

Quick Start

The easiest path is upload-first. Install the skills, sign in, create a No Source headless project, upload the current directory into the environment, then let the agent run checks and return proof.

trycase login
trycase workspace list
trycase project create --source none --name local-preview --mode headless --size <chosen-size>
# Optional: only after user approval when a local dotenv file exists
trycase project secret import --project <project> --file .env.local
trycase project secret file add --project <project> --path .env.local --include DATABASE_URL,APP_SECRET
trycase env create --project <project> --size <chosen-size>
trycase env wait <env>
trycase fs upload <env> . . --respect-gitignore
trycase terminal open <env>
trycase terminal write <session> "npm install && npm run dev" --env <env> --enter
trycase computer browser goto <env> http://localhost:3000
trycase command wait <command>
trycase computer status <env> --json
trycase computer browser snapshot <env>
trycase computer browser screenshot <env>
trycase computer browser recording <env>
trycase artifact bundle <env>
trycase env destroy <env>

Pricing And Credits

Credits measure active environment time. Headless mode is the lower-cost route for most LLM verification, and desktop mode costs 1.5x the same size because it runs a visible Linux desktop and stream. The current credit unit is $0.001/credit, so 1,000 credits equals $1 of compute.

Pick size from the workload instead of a fixed default. Use nano only for clearly tiny work,small for lightweight apps, standard for general unknown apps, and larger sizes for Docker-heavy, JVM/Android, native build, monorepo, or disk-heavy tasks.

Size affects credit burn and resource headroom. For example, nano headless is $0.07/hr (66.6 credits/hr);standard headless is $0.17/hr ( 165.6 credits/hr).

Workspace subscriptions are managed from the pricing page. If the included credits in your plan are not enough, email ben@trycase.dev for a manual top-up.

Install

The published CLI connects to production by default. Use a one-off command runner, or install it globally when you want trycase available in every shell.

Agent Skills

Install the universal TryCase skills so your coding agent knows the upload-first route, how to run Linux apps in a disposable environment, how to refresh TryCase skills, how to keep the TryCase CLI current, and how to return proof instead of asking you to test manually.

Mental Model

TryCase has three product objects and a few command namespaces. Once these are clear, the CLI reads much more predictably.

Choose A Route

Most users should start with upload-first. Keep source control decisions outside TryCase for now: create a disposable environment, upload the working tree, run checks, collect proof, then destroy it.

# Visible desktop for live viewing, desktop APIs, or manual user action
trycase env create --project <project> --mode desktop --size <chosen-size>
trycase env wait <env>
trycase env view <env> --no-open
trycase desktop app launch <env> terminal
trycase desktop app launch <env> browser http://localhost:3000
trycase desktop screenshot <env>
trycase desktop recording start <env>
trycase desktop recording stop <env>
trycase env destroy <env>

# Blank cloud computer, no code checkout required
trycase project create --source none --name scratch --mode headless --size <chosen-size>
trycase env create --project <project> --size <chosen-size>
trycase env wait <env>
trycase fs upload <env> . . --respect-gitignore
trycase terminal open <env>
trycase terminal write <session> "printf 'console.log(2 + 2)\n' > scratch.js && node scratch.js" --env <env> --enter --wait-for 4
trycase env destroy <env>

Runtime Settings

If the uploaded working tree contains trycase.yaml, the runner reads that file inside the environment. If it is missing, TryCase falls back to saved project runtime settings from the dashboard or CLI. Runner size and environment mode are allocation settings selected before work starts, so set them with project defaults orenv create flags.

trycase project manifest generate \
  --project <project> \
  --runtime npm \
  --install "npm install" \
  --start "npm run dev" \
  --app-url http://localhost:3000 \
  --healthcheck http://localhost:3000 \
  --size <chosen-size> \
  --mode headless

trycase project create --source none --name preview --mode headless --size <chosen-size>
trycase env create --project <project> --mode desktop --size <chosen-size>
trycase computer status <env>

# Minimal No Source settings
version: 1
runtime:
  type: none
  size: standard
  mode: headless
  timeout_minutes: 60
artifacts:
  video: always
  screenshots: always
  logs: always
  traces: on_failure

version: 1
runtime:
  type: npm
  size: standard
  mode: headless
  timeout_minutes: 60
package:
  install: npm install
  start: npm run dev
  app_url: http://localhost:3000
  healthcheck: http://localhost:3000
secrets:
  required:
    - DATABASE_URL
  files:
    - path: .env.local
      include:
        - DATABASE_URL
  hooks:
    - command: node scripts/trycase-secrets.mjs
      run_at: before_install
      timeout_seconds: 30
artifacts:
  video: always
  screenshots: always
  logs: always
  traces: on_failure

Project Secrets

Use project secrets when an app needs environment variables, a generated dotenv file, or a setup command before it can install or start. Values are encrypted at rest, shared by every environment for the project, and never shown back to users.

# Set values without shell history
printf "%s" "$DATABASE_URL" | trycase project secret set \
  --project <project> \
  --name DATABASE_URL \
  --value-stdin

# Import an approved local dotenv file into encrypted project secrets
trycase project secret import --project <project> --file .env.local

# Require secrets and generate .env.local in every environment
trycase project secret required add --project <project> DATABASE_URL APP_SECRET
trycase project secret file add \
  --project <project> \
  --path .env.local \
  --include DATABASE_URL,APP_SECRET

# Optional framework-specific setup
trycase project secret hook add \
  --project <project> \
  --command "node scripts/setup-secrets.mjs" \
  --run-at before_install \
  --timeout 30

# trycase.yaml can declare the same metadata
secrets:
  required:
    - DATABASE_URL
    - APP_SECRET
  files:
    - path: .env.local
      format: dotenv
      include:
        - DATABASE_URL
        - APP_SECRET
  hooks:
    - id: setup-secrets
      command: node scripts/setup-secrets.mjs
      run_at: before_install
      timeout_seconds: 30

Command Reference

LLM Operating Guide

This flow is designed for coding agents that need to verify web apps, run arbitrary terminal work, collect proof, and use a real desktop only when the task needs one.

1. Start by running trycase login. If a browser cannot be opened, run trycase login --no-open and ask the user to approve the printed URL.
2. Run trycase workspace list. If no workspace is selected, run trycase workspace use <workspace> or trycase workspace create --name <name>.
3. For local project work, use the upload route. Inspect the repo first, choose the smallest likely size that fits memory, CPU, disk, and build needs, then create a No Source project with --mode headless --size <chosen-size>.
4. Before using local dotenv files, ask the user. If approved, import them with project secret import --file .env.local and generate dotenv files with project secret file add before creating the environment.
5. Create missing projects with trycase project create --source none --name <name> --size <chosen-size>. Keep workspace, project, command, and environment IDs in your notes.
6. Run trycase project list and pick the project ID.
7. Check runtime settings with trycase project manifest show --project <project>. If the uploaded working tree contains trycase.yaml, the runner reads that file inside the environment; otherwise it falls back to saved project settings.
8. If the project needs secrets, use project secret list, project secret required list, project secret file list, and project secret hook list before launching.
9. Never pass secret values in command arguments. Use project secret set --value-stdin, --env, --file, or project secret import --file .env.
10. Create the environment with trycase env create --project <project> --size <chosen-size>. Add --mode desktop when the task needs a visible desktop or a manual user step.
11. Do not use --mode computer; valid environment modes are headless and desktop. trycase computer ... is a command namespace for status and browser automation.
12. Run trycase env wait <env> before sending commands.
13. Use trycase env list --active --json before cleanup or after interruptions to discover any active billable environments.
14. After env exec or browser commands, run trycase command wait <command> to retrieve the result.
15. Run trycase computer status <env> --json to discover capabilities before using terminal, browser, filesystem, or artifact commands.
16. Use terminal open, terminal write, terminal wait-for, and terminal read for persistent CLI sessions. These sessions are controlled by the CLI and do not appear as windows in the live desktop.
17. Use fs write --file for one local file, fs upload <env> . . --respect-gitignore for a local directory, and fs artifact to turn generated files into artifacts. Directory uploads are capped by environment size: nano 2 GiB, small 4 GiB, standard 8 GiB, and large 16 GiB uncompressed.
18. Prefer computer browser snapshot before clicks. Use text or selector refs from the snapshot before coordinate clicks.
19. Use desktop app launch for Terminal, Chrome, and Files only on desktop-mode environments when the task requires a real visible computer instead of headless browser control.
20. If the app needs manual login, OAuth consent, CAPTCHA, passkey, 2FA/OTP, payment confirmation, account creation, browser extension approval, or another human-only step, use desktop mode, run trycase env view <env> --no-open, give the user the live desktop URL, ask them to take control there, and pause until they confirm the step is complete.
21. Never ask users to paste passwords, OTPs, or CAPTCHA answers into chat, and do not try to bypass anti-abuse checks.
22. Use desktop screenshot, desktop mouse, desktop keyboard, and desktop window commands to click, drag, resize, switch apps, and capture the visible desktop state.
23. Capture evidence with computer browser screenshot, computer browser recording, desktop screenshot, desktop recording, computer browser console, computer browser network, env logs, and artifact bundle.
24. Always end with trycase env destroy <env> or trycase env destroy --all-active --json, then confirm STOPPED - NOT BILLABLE.

# Recommended upload workflow
trycase workspace list
trycase project create --source none --name local-preview --mode headless --size <chosen-size>
trycase project secret list --project <project>
trycase project secret required list --project <project>
trycase billing status
trycase env create --project <project> --size <chosen-size>
trycase env wait <env>
trycase fs upload <env> . . --respect-gitignore
trycase computer browser goto <env> http://localhost:3000
trycase command wait <command>
trycase computer browser snapshot <env>
trycase computer browser screenshot <env>
trycase computer browser recording <env>
trycase artifact bundle <env>
trycase env destroy <env>

# Blank computer workflow
trycase project create --source none --name agent-scratch --mode headless --size <chosen-size>
trycase env create --project <project> --size <chosen-size>
trycase env wait <env>
trycase terminal open <env>
trycase terminal write <session> "printf 'console.log(2 + 2)\n' > scratch.js && node scratch.js" --env <env> --enter --wait-for 4
trycase env destroy <env>

# Desktop workflow when a visible window or manual user action is required
trycase env create --project <project> --mode desktop --size <chosen-size>
trycase env wait <env>
trycase env view <env> --no-open
trycase desktop app launch <env> terminal
trycase desktop app launch <env> browser http://localhost:3000
trycase desktop screenshot <env>
trycase env destroy <env>

Safety Checklist

• Do not print saved tokens or paste them into chat.
• Do not pass secret values as CLI arguments. Use stdin, environment variables, files, or dotenv import after explicit approval.
• Use generated dotenv files or hooks for framework-specific config instead of committing local secret files.
• Use No Source projects and upload the working tree for verification runs.
• Keep source-control changes in your normal local workflow. Do not modify a main branch just for verification.
• Use env destroy --all-active before stopping an automation-heavy session.
• Use env usage or env status to confirm active and billable state.
• Prefer snapshots and semantic refs for browser control; use coordinates only when necessary.
• For manual login, CAPTCHA, 2FA, payment, or other human-only flows, use desktop mode and the live desktop take-control link instead of asking for sensitive values in chat.

Troubleshooting