Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt

Use this file to discover all available pages before exploring further.

The Dynamic CLI (dyn) is the official command-line client for Dynamic. Every operation available in the dashboard is also available as a dyn command — over 200 commands spanning auth providers, users, webhooks, chains, custom fields, environments, projects, members, MFA, allowlists, custom hostnames, and gates. Use it to script repetitive tasks, diff sandbox against live, drive Dynamic from CI, and manage your configuration as code.
What you need: Node.js 18+ and a Dynamic account. The CLI authenticates through your browser against the Dynamic dashboard.

​
Install

npm install -g @dynamic-labs/dynamic-console-cli
This installs the dyn binary globally. Verify it: 
dyn --help

​
First commands

dyn auth login          # authenticate through your browser
dyn status              # show the active organization, project, and environment
dyn settings list       # discover every configurable project setting
After login the CLI auto-selects an environment so your next command works immediately. See Getting started for the full walkthrough.

​
Guides

Getting started

Install, authenticate, select an environment, and run your first commands.

Config as code

Snapshot an environment to YAML with dyn export and reconcile changes with dyn apply.

Managing embedded wallets

Configure embedded wallet creation, recovery, and notifications from the terminal.

Authentication & CI

Browser login for humans, DYN_CLI_TOKEN for automation.

Project settings

Read and write the dot-notation settings tree with dyn settings.

​
How Dynamic is organized

The CLI mirrors how Dynamic structures your data. Three nested layers, top to bottom:
  • Organization — your team or company. Owns billing and membership. Most users belong to one org.
  • Project — a single product or app inside an org. An org can have many projects.
  • Environment — a runtime slot inside a project. Every project has two:
    • Sandbox — for development and testing. Disposable data, safe to break.
    • Live — production. Real end-users, real wallets, real auth flows.
Every dyn command that reads or changes anything targets exactly one environment. Sandbox and live are fully isolated — settings, providers, users, and webhooks never bleed across. Use dyn environments switch to change which environment subsequent commands act on, and dyn status to see the current selection.

​
Command shape

Every command follows the same pattern: 
dyn <resource> <action> [args] [flags]
  • resource — a noun: providers, users, webhooks, chains, environments, members.
  • action — a verb: list, get, create, update, delete, enable, disable.
  • args — positional IDs or names.
  • flags — global flags plus action-specific ones.
When you don’t know which resource owns an operation, discover it instead of guessing: 
dyn --help                      # top-level resource list
dyn <resource> --help           # actions and flags for a resource
dyn <resource> <action> --help  # arguments, flags, and examples
dyn --help | grep -i webhook    # find the resource that owns an operation
Add -o json to any command to get machine-readable output for piping into jq, or -o yaml to feed into dyn apply.