Quick start
Install once, run init, restart your app.
For common providers, you should not need to edit application code. The init tool reads your environment files, protects detected keys, and writes the VaultProof values your SDKs need.
curl -fsSL https://vaultproof.dev/install | sh
vaultproof-initOPENAI_BASE_URL. The CLI handles the setup and tells you what changed.
Works from your project root
Run the command where your app keeps env files like .env, .env.local, .env.production, or .env.development.
No raw key in the app
Your app uses the VaultProof token in place of the original key. The real provider credential is reconstructed only inside VaultProof when a call is routed.
One test before deploy
Restart your local app and trigger one provider request. Check Activity Logs for the call before pushing the same env values to production.
What's built
The current consumer surface on vaultproof.dev.
Use this map to understand which customer-facing pieces are already present in the site and app, and which workflow each one supports.
| Surface | URLs or entry points | What it does |
|---|---|---|
| Marketing and pricing | /, /compare, /v2 |
Explains active key protection, provider-compatible proxying, plan limits, and how VaultProof compares with traditional secret stores. |
| Hosted installer and downloads | /install, /downloads/vaultproof-init.mjs, /downloads/providers.json |
Installs the CLI, ships the hosted init bundle, and provides the provider catalog fallback used during setup. |
| Consumer app | /app/login, /app/, /app/keys, /app/activity, /app/alerts, /app/settings, /app/plans |
Handles login, project monitoring, protected keys, request activity, alert review, account settings, and billing or plan workflows. |
| Repository scanner | /scan, /app/scanner |
Finds exposed keys and migration opportunities from public checks or the authenticated GitHub scanner flow. |
| Proof, status, and trust pages | /verify, /security, /status, /privacy, /terms, /abuse |
Shows the verification story, security model, public service health, legal policies, privacy posture, and abuse reporting path. |
| Init worker and proxy | init.vaultproof.dev/health, /api/v1/init/projects, /p/:provider/*, /v1/* |
Backs project setup, key storage, dashboard data, provider proxy routes, Stripe-native path support, audit, alerts, members, and org APIs. |
CLI modes
Pick the workflow that matches the secret.
The hosted CLI now handles regular provider keys, unsupported HTTPS APIs, vault-only runtime secrets, NetOps automation files, dry-run audits, legacy migration, and connectivity checks.
vaultproof-init
vaultproof-init --dry-run
vaultproof-init custom
vaultproof-init secrets add
vaultproof-init secrets pull
vaultproof-init run -- npm run dev
vaultproof-init netops
vaultproof-init netops run -- ansible-playbook site.yml
vaultproof-init --check-legacy
vaultproof-init doctorProvider proxy keys
Use vaultproof-init for HTTP API keys in supported SDKs. The CLI scans env files, protects detected keys, writes VAULTPROOF_PROJECT_ID, and adds provider base URLs.
Dry-run audits
Use vaultproof-init --dry-run before changing a repo. It reports scanned files, detected keys, and existing VaultProof markers without uploading or rewriting values.
Custom/internal APIs
Use vaultproof-init custom when the key belongs to a private or unsupported public HTTPS API. The CLI asks for the upstream URL and auth header format.
Vault-only secrets
Use vaultproof-init secrets add for values like DATABASE_URL, JWT_SECRET, OAuth client secrets, and webhook signing secrets that cannot be proxied as HTTP provider keys.
Secret injection
Use vaultproof-init run -- <command> to inject vault-only secrets into a child process, or vaultproof-init secrets pull to write a local plaintext file with mode 0600.
NetOps automation
Use vaultproof-init netops for Ansible inventories, group_vars, host_vars, Terraform tfvars, and automation credentials that should be injected at runtime.
vaultproof-init doctor when setup feels off.
The doctor command checks login, worker reachability, proxy connectivity, provider catalog loading, and existing VaultProof markers before you debug app code.
Onboarding
Get your first app into VaultProof.
Use this checklist when setting up a project for the first time.
-
1
Create or sign in
Open the VaultProof app, sign in, and keep the dashboard open while you run setup. The CLI may open the browser so it can connect the app to your account.
-
2
Run the hosted installer
The installer downloads the CLI from
vaultproof.dev/downloads, verifies the hosted manifest, and installs a bundled provider catalog for offline fallback. -
3
Choose the setup mode
Run
vaultproof-initfor provider proxy keys,vaultproof-init customfor unsupported HTTPS APIs,vaultproof-init secrets addfor vault-only runtime secrets, orvaultproof-init netopsfor automation repos. -
4
Restart and test
Restart your local server so the new env values load. For vault-only secrets, start through
vaultproof-init run -- <command>. Trigger one real workflow, then open Activity Logs to confirm the result.
Connect your site
Move from local setup to production.
After local setup works, copy the generated VaultProof proxy values into your hosting provider. This is the part most teams need for Vercel, Netlify, Cloudflare Pages, Render, Railway, Fly.io, or a custom server.
Local env file
Your env file should now include a generated VaultProof block. Proxy keys receive VaultProof project and base URL values; vault-only secrets become vaultproof:// placeholders.
# Generated by vaultproof-init
VAULTPROOF_PROJECT_ID=vp-proj-...
OPENAI_API_KEY=vp-proj-...
OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
DATABASE_URL=vaultproof://DATABASE_URLProduction env values
In your hosting dashboard, replace raw provider API keys with the generated VaultProof token and add any generated *_BASE_URL values. Then redeploy.
- Use the same env variable names your app already reads.
- Remove the old raw provider key from production secrets.
- Redeploy or restart so the new values load.
- Check Activity Logs after the first production call.
vaultproof-init run -- <command>; if a host cannot run that wrapper, keep that class of secret in your existing host secret manager.
Dashboard
What each page is for.
The app is organized around monitoring, managing protected keys, and reviewing security events.
Dashboard
See proxy calls, success rate, latency, and active routes. Use this page first after onboarding to confirm traffic is flowing through VaultProof.
API Keys / Protected Keys
Review VaultProof tokens and the provider keys attached to them. Use this page to add keys manually, rotate a protected key, or delete a token you no longer use.
Activity Logs
Filter requests by project, provider, status, endpoint, and time. This is the fastest way to answer, "Did my app call the provider through VaultProof?"
Security Alerts
Review suspicious usage, provider failures, limits, and incidents that may need action. Alerts should be handled before they become production issues.
Repository Scanner
Connect GitHub to find accidentally committed keys and migration opportunities. Scanner findings help you rotate, replace, or ignore detected secrets.
Settings and Plans
Manage account access, guardrails, billing, and usage limits. If you hit a plan limit, upgrade before production traffic starts failing.
Public tools
Use the supporting pages when you need proof, health, or examples.
The vaultproof.dev site includes more than setup docs. These pages help users validate security claims, check service status, preview the app, and find the right implementation guide.
Setup guides
Use /guides for the basic setup walkthrough and /cicd-kubernetes for CI/CD, Kubernetes, and existing secrets-stack positioning.
Scanner
Use /scan for the public scanner entry point and /app/scanner when an authenticated GitHub scan, scan history, or finding workflow is needed.
Verify and security
Use /verify and /security to explain what VaultProof can and cannot see, how split shares work, and what metadata is logged.
Status and demo
Use /status to check public site, init/proxy edge, API control plane, and dashboard health. Use /demo to preview the product without a live setup.
Providers
Provider catalog: 250 signatures.
The live provider catalog is version 9 and was last updated on 2026-05-21. vaultproof-init downloads /providers.json on each run and uses it to detect keys, choose env names, and configure provider routes.
AI and model APIs
OpenAI, Azure OpenAI, Anthropic, Groq, xAI, OpenRouter, DeepSeek, Mistral, Together AI, Fireworks AI, Cohere, Replicate, Hugging Face, Perplexity, Cerebras, ElevenLabs, Pinecone, Stability AI.
Payments and commerce
Stripe, Paystack, Lemon Squeezy, Mollie, GoCardless, Mercado Pago, Wise, Square, and related API-key based services.
Email and messaging
Resend, SendGrid, Brevo, Mailgun, Postmark, SparkPost, MailerSend, Mailjet, Mailtrap, Loops, Courier, Customer.io.
DevOps and infrastructure
GitHub, GitLab, CircleCI, Buildkite, Semgrep, SonarQube Cloud, Snyk, Codecov, LaunchDarkly, HCP Terraform, Pulumi, npm Registry, Doppler, DigitalOcean, Netlify, Render, Railway, Fly.io, Supabase, PlanetScale, Neon.
Observability
Sentry, New Relic, Datadog, Honeycomb, Better Stack, LogSnag, Raygun, Rollbar, BugSnag, Axiom.
Product and workflow
Linear, Notion, Figma, Asana, ClickUp, monday.com, Todoist, Coda, Shortcut, Webflow, and more.
vaultproof-init custom and follow the prompts. The CLI can protect custom or internal API keys when you provide the public HTTPS upstream and auth header format.
Daily operations
How to work with VaultProof after setup.
| Task | Where to go | What to do |
|---|---|---|
| Preview changes | vaultproof-init --dry-run |
Scan env files, provider matches, and existing VaultProof markers before uploading or rewriting anything. |
| Confirm traffic | Dashboard or Activity Logs | Look for the provider, endpoint, status, and latency after your app makes a request. |
| Add another provider | Run vaultproof-init again |
Add the provider key to your env file, rerun init, restart, and test. |
| Rotate a key | Protected Keys | Paste the rotated provider key into the existing token so your app can keep the same VaultProof value. |
| Deploy to production | Your hosting provider | Copy generated VaultProof env values to production secrets and redeploy. |
| Run vault-only secrets | vaultproof-init run -- <command> |
Inject non-proxy secrets into the child process instead of leaving plaintext values in the env file. |
| Run automation | vaultproof-init netops run -- <command> |
Inject Ansible or Terraform secrets after NetOps files have been rewritten to runtime environment lookups. |
| Check service health | /status or vaultproof-init doctor |
Confirm whether an issue is local to your app, auth session, provider route, or VaultProof's public services. |
| Investigate errors | Security Alerts and Activity Logs | Check status codes, provider failures, limits, and whether the request reached VaultProof. |
Troubleshooting
Common user fixes.
These are safe checks for the app owner. If you are supporting customers from the admin console, use the separate admin support guide.
The app still calls the provider directly
Restart your app and confirm the generated *_BASE_URL values are loaded in the same environment your process uses.
The provider call returns unauthorized
Check that the protected key exists on the Protected Keys page. If you rotated the upstream provider key, update it in VaultProof too.
Init did not find a key
Confirm the key is in one of the scanned env files and uses a provider shape in the catalog. For internal services, run vaultproof-init custom.
Production works locally but not after deploy
Compare local env values with hosting secrets. Production usually fails when an old raw key, missing base URL, or stale deployment is still active.
A vault-only placeholder reaches the app
Start the process with vaultproof-init run -- <command>. A value like vaultproof://DATABASE_URL is a placeholder, not the plaintext secret your database client can use.
CLI login or proxy checks fail
Run vaultproof-init doctor and check /status. If login is stale, sign in again at /app/login and rerun the command from the project folder.
vaultproof-init doctor or --dry-run output. Do not send raw provider keys.
FAQ
Short answers.
Is the VaultProof token a raw provider key?
No. The VaultProof token routes traffic to the protected key stored in VaultProof. It does not reveal the original provider credential.
Do I need a VaultProof SDK?
No for the normal setup path. The init tool configures supported providers so existing SDKs can keep working through generated environment values.
Can I commit the generated env block?
VAULTPROOF_PROJECT_ID and generated provider proxy values are designed to be less sensitive than the raw provider key, but follow your team's policy for env files. Never commit original raw provider keys or plaintext vault-only secrets.
What if I use an internal API?
Run vaultproof-init custom. The CLI will ask for the upstream HTTPS URL and the header format used by that service.
When should I use vault-only secrets?
Use vaultproof-init secrets add for secrets that are not provider HTTP API keys, such as database URLs, JWT/session secrets, OAuth client secrets, and webhook signing secrets. Run the app through vaultproof-init run -- <command> when it needs those plaintext values.
What does NetOps mode protect?
vaultproof-init netops scans common Ansible and Terraform secret locations, rewrites values to runtime environment lookups, and lets you inject them with vaultproof-init netops run -- <command>.