CLI Configuration

The dya CLI reads configuration from four places: a project file, a per-user global config, key files in the working directory, and command-line flags. This page documents each one and the order they are resolved in.

Project config

dya init and dya setup write a file named .deployyourapp in the current directory. It is JSON, it is meant to be committed, and it links the directory to an app on the server.

{
  "appId": "com.example.shop",
  "channel": "production",
  "path": "dist/spa"
}

The file is written with two-space indentation and a trailing newline. Missing or malformed JSON is treated as "no project config": dya deploy and dya rollback then exit 1 and tell you to run dya init.

When path is null, dya init and dya deploy auto-detect it by trying dist/spa, dist/pwa, dist, www, build, public in that order and accepting the first directory that contains an index.html. Nested outputs are checked before their parents so a dist folder holding only subdirectories never shadows the real assets.

Which commands read it:

Global config

Credentials and the active organization live in a per-user JSON file outside your project, managed by the conf package. It is created with 0600 permissions because it holds a session token or API key. You normally never edit it by hand.

File location

The file is named config.json and lives in the per-user config directory for dya-nodejs:

Because the config is per-user and not per-project, one login covers every project on the machine, and one dya orgs switch changes the organization for all of them.

Authentication headers

token and apiKey are never both used. An API key is sent as X-API-Key. A session token is sent as both an Authorization: Bearer header and a dya.session_token cookie. When both values are somehow present, the API key wins.

Key files

Signing and encryption are driven entirely by the presence of PEM files in the directory you run dya deploy from. There are no flags to turn them on.

dya keys generate writes all four, with 0600 on the two private keys (a no-op on Windows, where file permissions work differently). It also adds both private keys to .gitignore, creating the file if your project has none, and leaves any existing entries untouched.

The .gitignore entry stops the keys reaching a remote; it does not back them up. Keep copies in a password manager or secrets vault. Losing dya-signing-private.pem means you cannot ship another update that installed apps will accept — they verify against the public key already compiled into them. Leaking it means anyone can sign a bundle your users' apps will install and run.

Running dya deploy with no keys present stops and offers to generate them. In CI there is no terminal to prompt, so it deploys unsigned with a warning rather than minting a key that would vanish with the build agent.

For backward compatibility dya deploy falls back to .deployyourapp-private.pem for signing and .deployyourapp-encrypt.pem for encryption when the dya- names are absent.

Environment variables

The CLI reads no environment variable for authentication. There is no DYA_API_KEY or equivalent — an API key must be passed explicitly to dya login --api-key, typically from a shell variable your CI provides.

These variables do affect the CLI:

Precedence

For a value used by dya deploy, highest priority first:

1. Command-line flag — --channel beta, --path dist, --version 1.4.0.
2. Project config — channel and path from .deployyourapp.
3. Auto-detection or built-in default — the assets directory scan, production for the channel, 100 for the rollout, capacitor for the target, and a generated YYYY.MMDD.HHMMSS version.

The channel specifically resolves as flag > channel in .deployyourapp > production, and dya deploy and dya rollback share that one resolver. A bare dya rollback therefore targets the same channel a bare dya deploy shipped to. An empty or whitespace-only --channel is treated as if the flag were absent.

For the server URL, highest priority first:

1. --server <url> on the current dya login or dya setup invocation, which also persists it.
2. serverUrl in the global config, from an earlier --server.
3. The API_URL environment variable.
4. The built-in default, https://api.deployyour.app.

Note the ordering consequence: once --server has been used on a machine, setting API_URL has no effect. Run dya login --server <url> again to change it.

For the organization, highest priority first:

1. activeOrgId in the global config.
2. Auto-selection, when the account belongs to exactly one organization. The result is written back to activeOrgId.
3. Nothing — commands that need an organization exit 1 and ask you to run dya orgs switch.

Pointing at another environment

Almost nobody needs this. The CLI targets https://api.deployyour.app, the hosted service at deployyour.app, and that is the only environment most people ever use. --server exists for working against a different DeployYourApp API — a local server during development, or a staging environment:

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

DeployYourApp is a hosted service; there is no self-hosted distribution of the server to point this at.

The URL persists in the global config and applies to every later command, including dya setup. When the CLI is pointed at a non-default server, dya setup also writes updateUrl and statsUrl into the generated Capacitor plugin config so devices check the same server.

Related pages

• Command reference — every flag and its default.
• CI/CD integration — configuring the CLI in a pipeline.