feat: use get.agent-vault.dev short URL and add anonymous install beacon

[dangtony98]

Summary

• Swap the install one-liner from raw.githubusercontent.com/Infisical/agent-vault/main/install.sh to https://get.agent-vault.dev in docs/installation.mdx, docs/self-hosting/local.mdx, and web/src/pages/Register.tsx.
• Installer sends an anonymous install / upgrade beacon (OS, arch, version) to get.agent-vault.dev/ok on success; opt out with AGENT_VAULT_NO_TELEMETRY=1. Failure is swallowed so it never breaks an install.
• Docs call out the beacon and opt-out via a <Note> on the install page.

Test plan

• Run curl -fsSL https://get.agent-vault.dev | sh on macOS (fresh install) — binary lands in /usr/local/bin, beacon fires with event=install.
• Re-run on same machine — beacon fires with event=upgrade.
• Run with AGENT_VAULT_NO_TELEMETRY=1 — no beacon request.
• Install still succeeds if the beacon endpoint is unreachable (simulate with bad DNS / firewall).
• Register page renders the new command and copy-to-clipboard still works.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
agent-vault	🟢 Ready	View Preview	Apr 21, 2026, 12:39 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[claude]

🔴 The telemetry opt-out command documented in install.sh (line 12) and docs/installation.mdx is syntactically incorrect: AGENT_VAULT_NO_TELEMETRY=1 curl -fsSL https://get.agent-vault.dev | sh sets the variable only in curl's environment, not in the downstream sh process that actually checks it — so the beacon fires regardless. Fix by moving the prefix to sh: curl -fsSL https://get.agent-vault.dev | AGENT_VAULT_NO_TELEMETRY=1 sh, or use export AGENT_VAULT_NO_TELEMETRY=1 && before the pipeline.

Extended reasoning...

What the bug is and how it manifests

The install.sh comment (line 12) and the docs/installation.mdx <Note> both document the telemetry opt-out as:

AGENT_VAULT_NO_TELEMETRY=1 curl -fsSL https://get.agent-vault.dev | sh

This syntax is incorrect. In POSIX shell, a VAR=value prefix on a command sets that variable only in the environment of the immediately following command — here, curl. It does not propagate to subsequent stages of the pipeline. The sh process that fetches and executes the downloaded script is a separate process that inherits from the parent shell's environment, where AGENT_VAULT_NO_TELEMETRY is not set.

The specific code path that triggers it

At install.sh line 186 (in the new main() block added by this PR), the script checks:

if [ -z "$AGENT_VAULT_NO_TELEMETRY" ]; then

When a user follows the documented procedure, sh sees AGENT_VAULT_NO_TELEMETRY as empty (because curl consumed the prefix, not sh), the condition is true, and the beacon fires unconditionally.

Why existing code doesn't prevent it

The check itself is correct — it correctly gates the beacon on the variable being non-empty. The problem is purely in the documentation: the example command sets the variable in the wrong process. No runtime guard exists to detect or compensate for this mis-invocation.

What the impact would be

Users who explicitly follow the documented privacy opt-out procedure will still have their install telemetrized without their knowledge or consent. This silently violates stated user intent and contradicts the privacy promise made in both the script comment and the docs Note. Since this is a new feature introduced by this PR, the broken opt-out ships alongside the first deployment of the beacon.

How to fix it

Two correct forms exist:

1. Move the prefix to sh (the process that actually uses it):

curl -fsSL https://get.agent-vault.dev | AGENT_VAULT_NO_TELEMETRY=1 sh

2. Export the variable before the pipeline:

export AGENT_VAULT_NO_TELEMETRY=1 && curl -fsSL https://get.agent-vault.dev | sh

Both install.sh line 12 and docs/installation.mdx should be updated with the correct form. The docs Note currently says only Opt out with AGENT_VAULT_NO_TELEMETRY=1`` without showing any command — it should show the correct invocation explicitly.

Step-by-step proof

1. User reads the docs/installation.mdx Note or the install.sh comment and decides to opt out.
2. User runs: AGENT_VAULT_NO_TELEMETRY=1 curl -fsSL https://get.agent-vault.dev | sh
3. The shell forks curl with AGENT_VAULT_NO_TELEMETRY=1 in its environment; curl downloads the script and writes it to the pipe. AGENT_VAULT_NO_TELEMETRY plays no role in curl's behavior.
4. The shell simultaneously forks sh to read from the pipe. sh inherits the parent shell's environment, which has no AGENT_VAULT_NO_TELEMETRY variable set.
5. The script runs inside sh; at line 186, [ -z "$AGENT_VAULT_NO_TELEMETRY" ] evaluates to true (variable is unset/empty).
6. The beacon curl -fsS -m 3 "https://get.agent-vault.dev/ok?..." fires.
7. User believes they opted out; telemetry was collected anyway.

Empirical confirmation: running TEST=1 true | bash -c 'echo ${TEST:-UNSET}' outputs UNSET, proving the variable does not cross pipeline stage boundaries.

[dangtony98]

Addressed all four review comments in bae6cee:

1. 🔴 Opt-out command syntax — The env var now sits before sh in both install.sh (header comment) and the docs Note, so the downstream shell actually reads it:

   curl -fsSL https://get.agent-vault.dev | AGENT_VAULT_NO_TELEMETRY=1 sh

2. 🟡 Missing telemetry Note in docs/self-hosting/local.mdx — Mirrored the disclosure after both the install command and the upgrade command.
3. 🟡 AGENT_VAULT_NO_TELEMETRY missing from canonical env-var refs — Added to .env.example, a new "Installer" subsection in docs/self-hosting/environment-variables.mdx, and a new "Installer" section at the bottom of docs/reference/cli.mdx. Each entry notes the variable is installer-only (not read by the server or CLI binary).
4. 🟣 Pre-existing BACKUP_FILE bug — Both message sites now gate on [ -n "$BACKUP_FILE" ] so a reinstall over a binary-only install (no database file) no longer prints a blank path while claiming a backup was made.