DevVault

Your searchable memory for errors, fixes and snippets.

Sign in with a recovery code

For when email is not an option. Each code works exactly once — you got them when you generated recovery codes in Settings.

Back to email reset

Privacy · Terms of use

DevVault v2.16.0 · Sep 2026

What DevVault keeps, what it never collects, and who can see what. In plain words, and only what the software actually does.

The short version

It keeps what you and your apps put into it, and nothing else. No advertising, no analytics, no tracking. Your data is not sold or shared.
It does not collect your source code. The error handlers send only the error: its message, stack trace, file names and line numbers. The fix checker reads your code on your computer, and sends DevVault only the solutions you approve (see below).
An app's token can only send errors in. It cannot read anything stored in DevVault. A fixes token can read one workspace's errors and add solutions to them, and nothing else.
Only the members of a workspace see what is in it. Your personal vault is yours alone.
Secrets are protected. Account passwords, recovery codes and API tokens are stored only as one-way hashes. Saved login passwords (Credentials) are encrypted.

What DevVault stores

Your account	Name, email address, an optional recovery email, your password as a one-way hash (it cannot be read back), recovery codes as hashes, and when you agreed to these terms and this notice.
What you save	Errors, solutions, snippets, commands, playbooks, links, tasks, tags and attached files, in the workspace you save them in. Each solution records who wrote it.
Credentials	Usernames and URLs as you enter them; passwords encrypted in the database. Only workspace members with credential access can open them.
Errors your apps send	The error message, stack trace, project name, environment, language and framework (see what the handlers send).
API tokens	A name, what the token may do, the workspace it belongs to, and when it was last used. The token itself is stored only as a hash: DevVault shows it once, when you create it, and never again.
Signed-in devices	Each session's browser and IP address, so you can see where you are signed in and sign other devices out (Settings → Account).
In your own browser	A session cookie to keep you signed in, and a few display preferences (light or dark, collapsed sections, playbook progress) kept in your browser only and never sent to DevVault.

What DevVault does not collect

Your source code or repository. DevVault never connects to your Git host.
Your app's database, or its users' data, except where it appears inside an error message (see the next section).
Analytics, tracking or advertising data. There are no tracking scripts and no tracking cookies.

What the error handlers send

The code you add to your app from the integration guide sends each error once, with its message, its stack trace (which names files, line numbers and functions), a project name and an environment. It does not send your code, your database, or any form or query data. The Node.js and Python handlers also label each error with the request's method and page path, such as GET /orders/15, so you can tell which page failed.

One thing to know: an error message contains whatever the code put in it. If a message includes a value, such as an email address in "Duplicate entry 'ana@example.com'", that text is stored like the rest of the error. To keep personal data out:

Avoid putting personal data into your own exception messages.
Keep PHP's zend.exception_ignore_args = On (the production default), so stack traces do not include function arguments.
Delete an error in DevVault if it ever captured something it should not have.

API tokens: what each one can see

Token	Can	Cannot
App token (Log errors)	Send errors into one workspace.	Read anything stored in DevVault: not your errors, not your credentials, nothing. All it ever gets back is the number of the error it just sent, and, from the connection check, its own name and its workspace's name. A leaked one gives nothing else away.
Fixes token (Read errors, Add solutions)	Read the errors of one workspace, and add solutions to them.	See any other workspace, your credentials, snippets or anything else; edit or delete anything.

Every token works only while its owner is still a member of its workspace, and you can revoke any token at once on the API tokens page. The members of a shared workspace can see who made each token for it, its name, what it can do and when it was last used, but never the token itself; the workspace's owner can revoke any of them.

The fix checker and your code

It runs on your computer, next to your code. Your code and your Git history are read there and are not uploaded anywhere.
It reads your open errors from DevVault, using your fixes token.
Nothing is sent back unless you choose. When you add solutions, DevVault receives, for each error you ticked: the solution text, the ticket link, and the change from the fixing commit to that one file (at most 200 lines). You can read exactly that on screen before anything is sent.
Your token stays with you. The browser version runs only on your own computer (127.0.0.1). If you tick Remember, the address and token are saved in your user folder (.devvault/fixes.json), never inside the project, so they cannot end up in Git.

Who can see what

Your personal vault: only you.
A shared workspace: its members. Credentials only to members given credential access.
Administrators of this DevVault can create, suspend and delete accounts and send password-reset links. The app gives them no view into other people's workspaces.
Whoever runs the server has access to its database, as with any web application. That is why passwords and tokens are stored only as hashes, and credential passwords encrypted.

Outside services

Page styles and fonts load from jsDelivr (a public code library service) and Google Fonts. Like any website, your browser sends them its IP address and browser details when a page loads. They receive nothing from inside DevVault.
Error alerts go only where a workspace's owner points them (Settings → Alerts): a Slack, Microsoft Teams or Google Chat channel, or an email address. Each carries the error's title, number, project, how often it happened and a link; never the stack trace or the full message. Once there, it is kept by that service under its own terms.
Email is sent through the mail service this DevVault is set up with: sign-up verification, password resets, workspace invitations, and the Monday digest, which goes only to confirmed addresses and not at all in a quiet week.

How long things are kept, and deleting them

What you save stays until you delete it. Deleting a workspace deletes everything in it.
You can export your vault at any time (Settings → Export).
Nightly backups are kept for 14 days. Saved credential passwords go into a backup only when it is encrypted with a backup password.
Server logs are kept for 14 days.
You can delete your account yourself (Settings → Account → Delete your account). Your name, email, password and recovery details are removed, and so is your personal vault with everything in it. What you wrote in shared workspaces stays with the team, shown as by “Deleted user”, because it is part of their shared record. Shared workspaces you alone own pass to their longest-standing member. Your API tokens stop at once.
An administrator can also suspend an account (it cannot sign in and its tokens stop, and nothing is deleted), or delete it in the same way. The admin log keeps who did it, the account's former name, and the reason given.
To ask what is held about you, contact DevVault at support@fsulit.net.

How it is protected

Passwords, recovery codes and API tokens are stored as one-way hashes; credential passwords are encrypted.
Every token is limited to one workspace and to what it was created for, and to 60 requests a minute.
Pages refuse to be shown inside other websites, so they cannot be used for click-jacking.
Changing your password signs out your other sessions; you can also sign devices out yourself.

Questions

This DevVault is run by DevVault. For questions about your data, contact them at support@fsulit.net. See also the terms of use.

The rules for using this DevVault, in plain words. It is run by DevVault.

What DevVault is. A place to keep the errors you hit and what fixed them, with snippets, commands, playbooks, links, tasks and credentials for your work. The privacy notice explains exactly what it stores and who can see it.
Your content stays yours. DevVault stores it so you and your workspace can use it. It is not sold, shared, or used for anything else. You can export it at any time.
Only put in what you are allowed to. Save only information you have the right to keep here. Do not store other people's personal data unless your work needs it, and do not save passwords or secrets you are not permitted to share with the members of that workspace: everyone in a shared workspace can see what is in it, and credentials are visible to members given credential access.
Keep your access safe. Keep your password, recovery codes and API tokens to yourself. Put an app's log-only token in that app's settings, never in source control. Keep a fixes token on your own computer. Revoke a token as soon as you think it has leaked.
Use it fairly. Do not try to reach other people's workspaces, get around the limits on tokens and requests, overload the service, or upload anything harmful.
The fix checker. It runs on your computer and only writes to DevVault when you choose. You decide which solutions it adds; check them, as you would any change you make.
No guarantees. DevVault is provided as it is. It is backed up every night, but keep your own export of anything you cannot afford to lose, and do not rely on it as the only copy of important information.
Accounts. You can delete your own account at any time, from Settings → Account. The administrators of this DevVault can create accounts, and may suspend or delete one, for example when someone leaves the team or breaks these terms.
Changes. If these terms change, the date below changes, the change is listed under What's New, and you are asked to agree to the new version before carrying on.
Questions. Contact DevVault at support@fsulit.net.