CLI Installation

The DeployYourApp CLI is published as @deploy-your-app/cli and installs a single binary named dya. This page covers installing it, signing in, and linking your first project.

Requirements

The published package is a single pre-bundled file with no runtime dependencies, so a global install pulls nothing else in.

Install

npm install -g @deploy-your-app/cli

With pnpm or yarn:

pnpm add -g @deploy-your-app/cli
yarn global add @deploy-your-app/cli

Verify the install

dya --version

0.2.1

dya --help lists every command. dya <command> --help shows the flags for one command. Both exit with status 0.

Authenticate

Browser login

Run dya login with no flags. The CLI opens a pending authorization on the server, prints where to approve it, and polls until you do. Nothing listens on your machine, so this works over SSH, inside containers, and when your browser runs on a different host entirely.

dya login

ℹ Authenticate your account at:
  https://app.deployyour.app/auth/cli-auth?session=cms9dczwb00006cu4ryck0hdc

Press ENTER to open in the browser...
- Waiting for you to authorize the CLI...
✓ Logged in as ada@example.com

The URL is printed before anything opens, so you can copy it to another machine or browser profile rather than using the default one. --no-browser skips the ENTER prompt and the launch entirely. A pending request expires after 10 minutes.

The minted session token is valid for 30 days. If verification fails, the stored token is discarded and the command exits 1. Two-factor authentication is enforced by the browser flow when your account has it enabled — the CLI never handles your password or authenticator secret.

See dya login in the command reference for how the flow is secured.

API key login

For CI, or any machine without a browser, pass an API key. Create one in the dashboard under Settings > API Keys — it is shown once.

dya login --api-key "$DEPLOY_YOUR_APP_API_KEY"

✓ Logged in with API key

The key is validated against the server before it is saved. A rejected key is not stored and the command exits 1. See CI/CD integration for pipeline examples.

Pointing at another environment

Skip this. dya login already targets deployyour.app with no configuration, and that is the service the CLI is built for.

--server exists for working against a different DeployYourApp API, such as a local server during development. The URL is persisted in the global config and used by every later command.

dya login --server http://localhost:3000

--server also works on dya setup.

Guided setup

For a Capacitor project, dya setup does the whole first-run in one interactive flow — it is the fastest path from a fresh install to a deployable project.

cd your-capacitor-app
dya setup

The wizard, in order:

1. Applies --server if you passed it.
2. Resolves your project layout and offers to move any stray keys or a legacy .deployyourapp config into .dya/.
3. Verifies that the project has at most one signing keypair, and that any dya-signing-public.pem is the public half of the signing private key. Either problem stops setup before anything is written — see dya setup.
4. Logs you in via the browser if no credentials are stored.
5. Selects your organization, auto-selecting when you belong to exactly one.
6. Checks for package.json and @capacitor/core, and warns before continuing if either is missing.
7. Lists existing apps so you can pick one, or creates a new app from a name and app ID you supply.
8. Prompts for a default channel and writes .dya/config.json.
9. Offers to generate RSA-4096 signing and encryption key pairs into .dya/. If capacitor.config.json already pins a public key nothing here can sign for, that offer becomes Generate a DIFFERENT keypair anyway (safe only if no build carrying <fingerprint> was ever installed)? and defaults to no.
10. Offers to install @deploy-your-app/capacitor-update-manager using the package manager detected from your lockfile.
11. Generates an init module and, with your confirmation, wires it into your app's entry point. A file it did not generate is never overwritten — the next free filename is used instead, and later runs keep using it. A module that is registered but missing from disk is written back rather than reported as already done.
12. Writes plugins.DeployYourApp into capacitor.config.json, or prints a snippet to paste when your config is .ts/.js. Replacing a publicKey already embedded there takes typing replace the signing key — see dya setup.
13. Offers to run npx cap sync.

dya init is an alias of dya setup — the same command under two names, so dya init also needs credentials, a reachable server, and a terminal.

Both require a terminal on stdin and stdout, so dya setup | tee setup.log is refused as well as a pipeline with no TTY at all — the wizard would otherwise start and then silently answer its own questions. In a pipeline they exit 1; commit .dya/config.json and run dya deploy directly instead. See CI/CD integration.

dya setup accepts --app-id and --channel to skip those two prompts:

dya setup --app-id com.example.app --channel production

Split project layouts

A Quasar project keeps the web app at the project root (package.json, src/, quasar.config.ts) and the Capacitor project in src-capacitor/ (capacitor.config.json, android/, ios/, a second package.json). Setup resolves both and works from either directory — run it from inside src-capacitor/ and it resolves up to the web root rather than treating the Capacitor directory as the project.

In such a layout the plugin is installed into both package.json files: the web root so the JS import resolves, and the Capacitor root so npx cap sync sees the native plugin. That mirrors how the official Capacitor plugins are already installed in these projects.

What setup leaves in your project

your-project/
  .dya/
    config.json                   # commit this
    dya-signing-private.pem       # never commit
    dya-signing-public.pem
    dya-encryption-public.pem
    dya-encryption-private.pem    # never commit
  .gitignore                      # gains the .dya/* block — commit it
  src/boot/dya.ts                 # or src/dya.js — yours to edit
  capacitor.config.json           # gains plugins.DeployYourApp

Commit .dya/config.json and the .gitignore block together. The block is .dya/* plus !.dya/config.json, and it has to be written that way — see Configuration. Setup writes it either through dya keys generate or, before moving a stray private key into .dya/, on its own; if your .gitignore already excludes the directory as .dya/, that line is replaced with .dya/* and the swap is reported. Whichever route wrote it, the CLI then asks real git check-ignore whether .dya/config.json is still ignored and names the file, line and pattern of anything that beat the block.

The init module's name is the one setup was free to use. If src/boot/dya.ts (or src/dya.js) already exists and setup did not write it, your file is left alone and the module lands as dya-update, dya-ota, and so on — whichever name it takes is the one that gets registered, and the one later runs go on using rather than creating a second module. See Generated init module.

Manual setup

For an Electron app, or if you want the pieces one at a time:

dya login
dya apps create --name "My App" --app-id com.example.app --platform electron
dya keys generate
npm run build
dya deploy --channel production --target electron

dya keys generate writes the key pairs into .dya/, adds the .gitignore block, and uploads the two public keys to the server. It needs an active organization and an app ID to upload to, the latter from --app-id or an existing .dya/config.json; without them it still writes the keys and prints Log in and set an active org (and app ID) to upload keys to the server., leaving dya keys upload for later. See the command reference for every flag.

Where credentials are stored

Credentials live in a per-user config file created with 0600 permissions, not in your project. dya logout clears the stored session token and API key. See Configuration for the exact path on each operating system.

Troubleshooting

dya: command not found — the npm global bin directory is not on your PATH. Find it with npm prefix -g and add that directory's bin (or the directory itself on Windows) to PATH.

Login times out — a pending authorization expires after 10 minutes. Re-run dya login.

The browser does not open — copy the printed URL into any browser, on any machine. Use dya login --no-browser to skip the launch attempt entirely.

Commands report "Not logged in" — run dya whoami to check which credential is stored, then dya login again.

dya setup finds the wrong project — it walks up from your current directory to the nearest package.json with a src/ directory, preferring any directory that already has a .dya/config.json. If it lands somewhere unexpected, run it from your web root explicitly.

Setup could not patch the entry point — the module was still written. Setup prints the exact line to add and where to add it. This happens by design on any ambiguity, because the CLI will not guess at an edit to your source. The one case where the module is not written either is when every candidate filename is already taken by a file setup did not generate; it then writes nothing at all, and the instructions it prints carry the module's full contents inline under a NAME placeholder, plus what to move or rename.

Setup stopped before writing anything — the project has two signing keypairs, or a dya-signing-public.pem that is not the public half of its private key. Both are checked before the project config, the plugin install and cap sync, because the embedded public key is the one your released apps trust forever. Resolve the keys and re-run. See dya setup.

Setup stopped: the plugin was not configured and `npx cap sync` was not run. — capacitor.config.json already embeds a different signing public key and you did not type replace the signing key, so nothing was written. Usually this is a clone of a project that has already shipped: get the private key for the embedded fingerprint from whoever made the first release rather than replacing it. See dya setup.