Privacy and Security

Privacy and security

Dashless has no hosted service, analytics, advertising, telemetry, or Dashless account. Data is sent only where the requested workflow requires it: the connected WordPress site, the configured deployment host, npm during the first locked Astro dependency installation, and optional discovery services after a WP Cloud release.

Credential setup

Dashless starts a loopback-only setup page. The page links to WordPress's Application Password authorization flow and sends the resulting credential directly to the local Dashless process. The password is never pasted into chat, returned in a tool result, or written into the Astro project.

Use a dedicated WordPress Application Password so it can be revoked without affecting another integration.

Local secret storage

• macOS: Login Keychain
• Linux: a mode-0600 secrets file
• Windows experimental support: a mode-restricted local file

The local application-data paths are:

• macOS: ~/Library/Application Support/Dashless
• Linux: $XDG_DATA_HOME/dashless or ~/.local/share/dashless
• Windows: %LOCALAPPDATA%\Dashless

DASHLESS_DATA_DIR overrides the directory for tests or managed environments.

Other local data

Dashless stores:

• WordPress URL, username, discovered capabilities, and connection metadata;
• stable draft-create keys used to prevent duplicates;
• staged changes and single-use preview locks;
• frontend and deployment configuration; and
• temporary preview and SFTP runtime records.

Configuration and editorial workflow state live outside the generated Astro repository.

CI credentials

The following environment variables provide an ephemeral connection:

• DASHLESS_WORDPRESS_URL
• DASHLESS_WORDPRESS_USERNAME
• DASHLESS_WORDPRESS_APP_PASSWORD

Dashless reads them from the process environment and does not persist them.

SSH and SFTP

SSH and WP Cloud deployments use a key or SSH agent already configured on the local machine. Dashless stores connection metadata such as host, user, port, and paths. It does not request or store an SSH password or private key.

WordPress and release boundaries

• WordPress is the sole source of production editorial content.
• Release files are checked against a SHA-256 manifest before WP Cloud activation.
• Server-executable files are rejected from static release uploads.
• The WP Cloud file router contains paths inside the selected release and never serves PHP from it.
• Release activation and rollback routes require an authenticated WordPress user who can manage options.
• Public reader endpoints validate and sanitize input, use rate limiting, and keep opaque tokens hashed where later lookup does not require the original token.

Disconnect and removal

The guarded disconnect_site workflow revokes the current Application Password in WordPress by default, removes the local secret and connection, and erases site-specific idempotency, staging, preview-lock, and preview-payload data.

It deliberately preserves WordPress content, the generated Astro project, and static releases. If remote revocation fails, the connection stays local so the operation can be retried. A user may explicitly request local-only removal and revoke the Application Password manually.

A normally installed WordPress companion removes its Dashless options through uninstall.php. A must-use companion must be removed by the host or SFTP administrator after another router is restored. Static releases are never deleted automatically.

Public-repository history

Before the repository was made public, its complete tracked history was checked for known access-token prefixes, private-key blocks, WordPress Application Password-shaped values, and credential-shaped filenames. No such values were found.

Reporting a vulnerability

Do not open a public issue for a suspected vulnerability. Follow the repository's private security policy.