Support
Support runs through the project's GitHub repository. There are no support tiers and no response-time commitments; requests are handled by maintainers in the open, which is also why the first step is a bundle that is safe to attach publicly.
Step one: collect a support bundle
vagaris support-bundle --out vagaris-bundle.json
The bundle is a single JSON document containing:
- Metadata — CLI version, platform, Node version, generation time.
- Config — the instance config with every secret-bearing value replaced.
- Doctor results — the full check set: config, deployment/auth mode, agent JWT secret, secrets adapter, storage, database, LLM provider, log directory, server port, server reachability, protocol version (when reachable), node identity and lease state.
- Node identity and lease state — redacted.
- Recent logs — the last 500 lines across the three newest log files (
--log-lines <n>changes the count), each line redacted. - Environment variable names — names only, never values.
Every field passes through the redactor: vendor API keys, tokens, connection strings, PII and raw customer content become stable [REDACTED:kind:hash] placeholders, so the same secret maps to the same placeholder across bundles without revealing it. Source code and database rows are never collected.
Options: -o, --out <file> writes the file (mode 0600) and prints { ok, path, bytes, doctor }; without it the bundle goes to stdout as JSON. --api-base <url> overrides the server to probe; -c, --config and -d, --data-dir select the instance.
Read the file before attaching it. If something you consider sensitive survived redaction, remove it and say so in the request — that is also a bug report for the redactor.
Step two: open the right request
All intake is on the repository's issue tracker, which offers three forms:
| Form | Use it for |
|---|---|
| Bug report | The CLI or the instance does something other than what these docs say. Requires the command you ran, expected versus actual, the exit code, and the bundle. |
| Support request | You cannot get something done and are not sure it is a bug — installation, onboarding, configuration, a run that will not claim. Requires what you tried and the bundle. |
| Security report | A hardening suggestion or a question about the Security Model. Vulnerabilities do not go here — see below. |
Open one at https://github.com/Cramraika/vagris/issues/new/choose. Questions and ideas that are not requests belong in the repository's Discussions.
Security
Report a vulnerability privately through the repository's GitHub Security Advisory form: https://github.com/Cramraika/vagris/security/advisories/new. Do not open a public issue. The advisory conversation is where the report is confirmed, fixed and disclosed.
What happens next
Triage. A maintainer labels the request (bug, support, security), confirms the bundle is present and readable, and reproduces from the command and exit code you gave. Requests without a bundle are asked for one first. A request that turns out to be a question is moved to Discussions; a request that turns out to be a vulnerability is converted into a private advisory.
Escalation. Anything that indicates data loss, a governance bypass (a spawn without a lease, a tool outside the allowlist, a privileged act performed locally), or credential exposure is escalated to the maintainers responsible for the security model and handled under the advisory process. A confirmed bug is tracked to a fix in the repository; the issue is closed when the fix is released, with the version noted.
Closure. You are asked to confirm on the new version. If the docs were wrong rather than the code, the fix is a docs change and the drift gate that checks these pages against the binary is what keeps it fixed.
Before you open a request
- Troubleshooting lists the exit codes and the common failures with their fixes.
vagaris doctor --repairfixes the local causes it can.vagaris versiontells you whether you are behind; a protocol mismatch (exit7) is fixed byvagaris update.