Project environments

Technical reference synchronized with Yard’s source. File names and development commands refer to the native app repository.

Project settings live in the Applications inspector. Every operation is shared with the CLI through YardKit; supervised project processes are owned by the running app.

Runtime versions

Environment shows Global and each installed PHP/Node version. A global selection follows later global changes; a pinned selection remains project-specific. PHP uses the existing isolated site registry and PHP-FPM pools. Node uses .nvmrc, including exact installed versions. Yard's command wrappers resolve the project runtime from the working directory. Project workers and Studio use the same environment. A missing pinned runtime produces an error rather than silently running a different version.

Sail projects show their container runtimes; host version selectors do not override container images.

Processes

Project Processes chooses frontend, Laravel queue worker, scheduler and broadcasting. Start Project applies that selection; Stop affects the project's processes, keeping shared infrastructure running. Laravel workers require artisan. Broadcasting requires the project's Reverb package/configuration. Sail workers run in the registered application container.

yard project:configure shop --frontend --queue --scheduler --no-broadcasting
yard project:start shop
yard project:processes shop
yard project:stop shop

Process preferences are stored under YARD_HOME/config/projects/<path-identity>/, separately from the repository, preserving unknown settings. Project paths containing spaces are supported.

Data isolation

Isolate this project separates the Laravel database, cache/Redis namespaces, queue, session cookie and mail inbox when the project already uses Yard's SMTP server; existing mail transports are preserved. This is project data isolation, not an operating-system security boundary. The existing workspaces feature still provides separate code checkouts and domains.

SQLite is copied using its online backup API, including committed WAL data.
MySQL/MariaDB and PostgreSQL receive a new empty project database. Run migrations before using it.
Project processes are stopped before changing managed environment keys. Frontend and Reverb receive separate loopback ports; existing explicit port preferences are honored or reported as conflicts.
Yard supplies automatic frontend port arguments to direct Vite scripts. Custom frontend commands keep their existing arguments and must be configured to use the project's allocated port themselves.
Disabling restores the original managed values, preserving subsequent manual edits and retaining isolated databases. It does not delete data.
Workspaces of an isolated project receive separate namespaces and default to an isolated database.

yard project:isolate shop
yard project:unisolate shop

Private environment backups stay outside the repository with owner-only permissions. Runtime pinning and data isolation are independent: a project can share a PHP version while keeping separate data.

Dependency security

Run Audit checks locked dependencies, including development dependencies, against package-registry advisories. It never upgrades packages, edits lockfiles or installs dependencies. The result records the lockfile fingerprint; a changed lockfile makes the previous result stale.

Composer and JavaScript projects use their matching package manager. Supported audit formats are Composer, npm, pnpm and modern Yarn; unsupported or missing tools/lockfiles are shown as incomplete checks rather than a clean security result. Registry access is needed and sends the dependency metadata required by the package manager's audit service. Audit findings are advisory data, not a complete application security review. JavaScript audit processes use a development environment, and npm explicitly includes development dependencies so an inherited production shell cannot silently omit them; see npm's audit configuration.

yard audit --site shop --json

The command exits unsuccessfully for vulnerabilities or incomplete checks. The inspector shows severity, affected package/version information, available fixes and advisory links. Results are stored privately in Yard's project tooling directory.

Database restore points

Named restore points support SQLite, MySQL/MariaDB and PostgreSQL using installed clients; no provider binary is downloaded automatically. Snapshots contain database data and stay in Yard's private storage. Checksums detect damaged files. Restore verifies that the point belongs to the current database connection and first takes a safety snapshot. Stop project writers before restoring. Database restore changes data; it does not revert source code or migrations on disk.

yard db:snapshot before-migration --site shop
yard db:snapshots --site shop --json
yard db:restore <snapshot-id> --site shop
# Non-interactive callers must explicitly confirm with --force.

Snapshot/restore operations for one project are serialized. SQLite restoration uses its backup API and preserves the live database inode. SQL clients receive credentials through their supported environment variables, not command-line arguments. Failed restoration preserves the safety restore point.

Diagnostics and reports

Diagnostics check the project directory, selected runtimes, manifests, installed dependencies, lockfiles, Laravel environment/key and configured SQLite file. Resolve opens the relevant settings, environment file or project terminal. These are read-only checks; an existing SQLite file is not proof that migrations ran, and these checks do not claim to verify database connectivity or end-to-end application health. The native Check action (and CLI --live) also makes a bounded HEAD request to nginx on loopback with the project's Host header; redirects are not followed. It identifies application/server errors and unexpected server responses that may indicate an occupied port.

yard site:doctor shop --json
yard site:doctor shop --live
yard site:report shop --output /tmp/shop-report --database /path/to/findings.sqlite --running
yard site:report shop --output /tmp/shop-report-with-logs --attach /tmp/test-output.log

A report is a new directory containing manifest.json, diagnostics.json, a readable summary, optional redacted findings SQLite and selected logs/screenshots. Existing output paths are never overwritten; partial reports are not published. It does not copy a live worktree, .env or application databases. Evidence databases must use the Yard test-report findings/builds schema. The source is queried read-only (SQLite may create its WAL index sidecars when needed); SQLite's backup API captures a consistent snapshot while other connections continue writing. Redaction changes only the exported copy. Selected text attachments are redacted; screenshots retain their visible contents. Reports are snapshots, not acceptance attestations.

The native export marks active Studio/Agents runs provisional. Dirty/changing/unavailable repository state also makes a report provisional. CLI callers should add --running while execution continues. The database and filesystem are not captured in one cross-system transaction, so a live export cannot represent a final run result. Generated reports and project data should not be committed.

The workspace, Settings, Mail and Logs sidebars remember collapse state. Each retains an accessible restore button; the Studio chat restores from its tools header without unmounting its conversation or stopping a stream. Command–K opens project actions with search and keyboard navigation.

Run Wave exposes model and effort controls for Build, QA and Review. These override only that reviewed run and leave saved/global configuration unchanged. Provider changes require reviewing the run again; unknown subscription or API costs are not presented as invented estimates. Studio labels an unlisted saved model as the current conversation's model and explicitly distinguishes inherited CLI effort from verified runtime effort.