Documentation

Start here

Use this account guide for the operating path: protect supported provider access, connect the generated configuration, make one normal provider request, and confirm the result in Activity Logs. The full technical reference covers the runtime model, provider catalog, CLI reference, and public security material in greater depth.

1. Confirm the workspace. Complete onboarding, then run the CLI dry run from the application directory and review every detected entry.
2. Apply deliberately. Protect only the entries you recognize, then review them in Protected Keys and restart the application with the generated configuration.
3. Verify with real traffic. Make a normal provider request and confirm its safe operational record in Activity Logs.

Protect your first key

Run the installer from the application directory that contains the environment files you intend to review. Start with a dry run so the CLI reports supported entries without uploading or rewriting anything.

When the dry-run results match your expectation, run the interactive setup and confirm the entries you want to protect.

Open Protected Keys to review and manage the protected entry. Retain a recoverable copy of any environment file you plan to modify. Do not commit the original values or the generated runtime configuration to source control.

Connect your application

For supported providers, keep the familiar SDK environment names and use the generated provider-compatible route settings. Restart the application so its process receives the new configuration, then test one normal call locally before carrying the same setup into staging or production.

Supported provider

Use the interactive vaultproof-init path and preserve its generated base URL settings.

Custom HTTPS API

Use vaultproof-init custom when the service is not represented in the provider catalog.

Vault-only runtime secret

Use vaultproof-init secrets add, then launch the local process with vaultproof-init run -- npm run dev.

Verify protection

After the application restarts, make one normal provider request through its existing SDK or HTTP client. Open Activity Logs and check for the corresponding operational record.

• RouteExpected provider or route category
• ResultExpected response status
• TimingRecent timestamp and plausible latency

Activity records expose safe operational metadata such as provider, route category, status, timestamp, and latency. They are not a store for provider credentials or request payloads.

Operate your workspace

Use the signed-in routes below as the source of current account state. This documentation page does not load metrics or call product APIs.

Respond safely

If a provider credential may have been exposed, rotate or revoke it at the provider and through the applicable VaultProof workflow. Then review recent Activity Logs for unexpected use and check Security Alerts.

For a repository finding, use the scanner’s guided remediation and verify the provider’s own dashboard. Protected runtime access can reduce where an original credential appears, but it does not remove the need to rotate a credibly exposed provider credential.

Usage and billing

Open Plans & Billing for the current plan, usage controls, and billing actions attached to this account. Treat that authenticated page as the source of truth; this guide does not infer entitlement or usage from local browser state.

• Free: 5 active protected keys and 5,000 protected calls per month.
• One-time 30-day trial: no card required and no automatic charge.
• When the trial completes, the account returns to Free limits.
• For paid upgrades, review proration before confirmation in the Plans & Billing workflow.

If an expected action is unavailable, first confirm that you are in the intended account and review the visible plan guidance. Contact support with the feature name and visible message only if the issue remains.

Troubleshooting

The CLI did not find an expected provider entry

Run vaultproof-init --dry-run from the directory containing the relevant environment file. If the service is not in the catalog, use vaultproof-init custom.

A protected request does not appear in Activity Logs

Confirm the application restarted with the generated configuration, make one normal provider request, and check the selected workspace and time range.

A provider request fails after setup

Run the connectivity check below, verify the provider’s service status and permissions, then compare the generated route configuration with the application environment.

Your session has expired

Sign in again. The safe return target brings you back to this account guide after authentication.

Scanner connection problems

Open Repository Scanner, reconnect GitHub, complete authorization, and confirm the intended repository appears before retrying the scan.

Check service status before contacting [email protected].

More reference

• Full technical referenceRuntime model, provider setup, CLI reference, and operational guidance.
• Provider guidesStep-by-step integration help for supported services.
• MCP security boundaryThe read-only MCP connection returns bounded, non-secret metadata and server-side placement guidance. It cannot accept, retrieve, reveal, or provision provider credentials.
• Security referencePublic protection model, controls, and limitations.
• SupportAccount, billing, scanner, CLI setup, dashboard, and protected-routing help.