Start a real project, add the parts you need, and give your AI assistant a clear map to work from.
One CLI helps you start and grow product projects without repeating the same setup work every time.
Use it when your project may need more than a single app: a website, an API, docs, a mobile app, a desktop app, shared libraries, local settings, and a way for AI assistants to understand the project.
One CLI gives you an empty workspace first. You can add apps, services, documentation sites, and shared libraries as the product grows.
Install on macOS or Linux:
curl -fsSL https://1cli.dev/install.sh | bashInstall on Windows 10/11 x64 from PowerShell:
irm https://1cli.dev/install.ps1 | iexBoth installers verify the release checksum and add one to the normal per-user binary location.
Create a workspace and add a project:
one create my-app
cd my-app
one add react-spa --name web
one dev -p webThat gives you a workspace, a first app, and a local way to run it.
One CLI is useful when you want to:
- start from a clean project foundation
- add a frontend, backend, docs site, mobile app, desktop app, or library later
- keep environment configuration and local settings organized
- let an AI assistant help without guessing how the project is arranged
- use the same simple commands across different kinds of projects
It is not trying to replace your package manager, editor, or hosting provider. It gives the project a shared shape so people, scripts, and AI assistants can work with it more safely.
One CLI includes starters for common product work:
| Need | Starters |
|---|---|
| Web apps | Next.js, React SPA, Astro |
| Backends | NestJS API, Go API |
| Documentation | Starlight docs |
| Mobile apps | Expo |
| Desktop apps | Electron |
| Shared libraries | TypeScript library, Go library |
See the available starters:
one templatesAdd one to an existing One CLI workspace:
one add nestjs-api --name api| Command | What it helps you do |
|---|---|
one create <workspace> |
Create an empty workspace |
one add <starter> |
Add another app, service, docs site, or library |
one env |
Review and manage environment variables |
one login |
Sign in to Infisical with your browser |
one serve |
Inspect workspaces, manage the current account and shared credentials |
one run [task] |
Discover and execute workspace tasks through mise |
one exec <project> -- <command> |
Execute a command with the selected project environment |
dev, build, test, and lint are task names. They all use the same shorthand: one <task> → one run <task>. For example, one dev runs one run dev, and one build -p web runs one run build -p web.
Full command docs live at 1cli.dev.
New workspaces include bilingual AGENTS.md guidance. Agents can inspect one run --list -o json, preview tasks with one run build --dry-run, and consult command-specific help.
You can ask an assistant for project-level changes in natural language, for example:
Create a product workspace with a web app and an API.
Add a docs site to this project.
Add a mobile app next to the existing backend.
The assistant can read one.manifest.json and project README files, then use One CLI commands with -o json to make project changes.
One CLI manages variables in Infisical and injects them directly into commands. Workspace bindings live in the top-level manifest env field; .env files are not loaded or exported. Run one login to sign in with your browser; the single session is stored in the OS keyring, with no plaintext fallback. Use one whoami to inspect status and one logout to remove the local session.
Run one serve for account settings, workspaces, and shared credentials. Workspace and project configuration changes share one reviewed, revision-checked Manifest draft. Remote variable edits take effect immediately; lists omit values and reveal/copy fetch plaintext only on demand.
Choose shared credential storage with one env bind --global. Agents discover environments and folders through one env --global and one env list --global, then execute with one exec --global --env dev --path /folder --keys KEY -- command. Explicit scope and best-effort masking reduce accidental exposure; they do not isolate arbitrary programs running as the same OS user. Use least-privilege remote permissions.
Every One CLI project has a one.manifest.json file at the root. Most users do not need to edit it by hand.
Think of it as the project map. It records which parts exist, where they live, and which starter created them. One CLI reads it when you add, run, build, or inspect parts of the project. one serve writes it only after an explicit reviewed, revision-checked Dashboard action; other repository changes stay in the normal code-review workflow.
If you want to work on One CLI itself, the repository is organized like this:
| Path | Purpose |
|---|---|
one.manifest.json |
The four projects managed by One CLI itself |
packages/cli |
The One CLI app and its public Go packages |
packages/kernel |
Shared Go kernel |
packages/templates |
Starters used by one add |
mise.toml |
Workspace scheduling, tools, and artifact cache declarations |
apps/docs |
Documentation website |
apps/dashboard |
Local workspace, account, and global-variable Dashboard opened by one serve |
assets |
Brand assets, including the logo |
This repository is also a One CLI workspace: dashboard, docs, cli, and kernel. Template directories under packages/templates and test fixtures are source assets, not registered projects. packages/cli keeps its existing location because it also exports Go packages with that module path.
Bootstrap a fresh checkout without requiring an installed one:
mise trust
mise install
mise run installThen use the workspace commands:
one # Inspect this workspace
one run # List root and project tasks
one dev # Dashboard API + Vite UI, using the development fixture
one dev -p docs # Documentation at http://localhost:3000
one build -p cli # Prepare embedded resources and build the CLI
one test -p kernel # Test the shared Go kernel
one run check # The complete repository gate; one check is shorthand
one serve # Manage this repository in the Dashboardone dev -p dashboard starts the Vite UI; run one dev -p cli in another terminal for its API, or use the combined one dev task. one serve opens this repository as a real workspace, while the contributor development API uses the existing test fixture. No Infisical binding is required to build, test, or start these projects.
Root tasks remain native mise commands, so CI and first-time installation can still use mise run build, mise run check, and mise run install. Project tasks come from package scripts and Taskfiles. Only the root mise.toml is used: project tasks are namespaced as cli:build or dashboard:dev and select their directory with dir. CLI tasks declare their embedded-resource prerequisites there; CLI tests also build the binary used by E2E tests. Run one init mise after changing the project task catalogue to refresh the tracked task adapters.
Read CONTRIBUTING.md before opening a pull request.
MIT.
one <task> is shorthand for one run <task>. Built-in commands take precedence; use one run env for a task that shares a built-in name.
one run test -p api # Explicit task entry
one test -p api # Same task through shorthand
one dev -p web -p api # Concurrent development services
one dev -p web --ui raw # Native terminal input for the selected service
one build -p web -p api --concurrency 4All tasks use mise for scheduling, including development and user overrides. Multiple services use prefixed logs; Ctrl+C or a task failure stops the invocation and its child processes. Raw mode preserves terminal input and disables artifact caching. The previous development TUI and single-service restart controls have been removed. Structured results stay on stdout and child logs go to stderr.
Build concurrency defaults to 1; development allocates it automatically. Local Node dependencies build before their consumers. one run build --cache off --force always executes the build. See the task guide for configuration, cache declarations, and Actions examples.