# Crudy Best Practices  Secure, Auditable Database Access

> Best practices for running Crudy in NIZU Cloud: use least-privilege database users, keep the agent on the database server, restrict connections to the right teams, rely on the audit log and trash (Ap…

- Page: https://dashboard.nizu.io/knowledge_base/view/154-crudy-best-practices-secure-auditable-database-access
- Part of: [Knowledge base](https://dashboard.nizu.io/knowledge_base/llms.txt) on NIZU — https://dashboard.nizu.io/llms.txt
- Updated: 2026-10-25T11:50:03Z

## Crudy best practices

Crudy is designed to make database access both convenient and safe. These practices help you keep it that way as more people in your team start using it.

### Security

- **Always use a least-privilege database user.** Grant only SELECT, INSERT, UPDATE and DELETE on the single database you want to browse. Never point Crudy at a root or admin account the agent can do no more than the user's grants allow, so a tight user is your strongest safeguard.
- **Keep the database private.** Let the agent make its outbound connection to the workspace; do not open your database port to the internet. There is nothing inbound to expose.
- **Run the agent close to the database.** Install it on the database server (or a trusted host on the same private network) and connect it to `127.0.0.1` or a private address where possible.
- **Protect the token.** The bearer token is a secret. Store it safely, and if it is ever exposed, regenerate it the old token stops working immediately and the agent must be re-installed with the new one.
- **Use a strong, unique database password** for the Crudy user, separate from any other account.

### Access control

- **Scope each connection.** Restrict every connection to the specific teams and members who genuinely need it rather than leaving it open to everyone.
- **Use roles deliberately.** Grant read-only browsing widely if helpful, but reserve create, update and delete permissions for the people who should be changing data. Keep trash restore and settings access to a small group.
- **Review who has access periodically**, especially after team changes.

### Working with data

- **Prefer saved views over repeated ad-hoc digging.** Build a view once for the questions you ask often; it is faster and less error-prone than rebuilding filters each time.
- **Filter before you edit.** Narrow down to the exact rows with search and saved filters so you act on the right record.
- **Double-check before deleting.** Deletes go to the trash and are recoverable, but it is still better to confirm you have the correct row first.
- **Refresh on busy tables.** If other apps write to a table while you browse, use Refresh to pull in the newest rows.

### Accountability and recovery

- **Trust the audit log.** Every insert, update, delete and restore is recorded with the user and the before/after values. Use it to answer "who changed this?" and to review activity.
- **Check the error log when something fails.** It shows the raw database error and the exact statement, which usually points straight at the cause (a constraint, a type mismatch, a missing column).
- **Recover from trash rather than re-typing.** If a row was deleted in error, restore it from the trash instead of recreating it by hand, so you keep its data intact.

### Operations

- **Keep the agent running as a service.** Installed as a service it starts on boot and reconnects automatically; check its status if a connection shows offline.
- **Keep the agent updated.** Re-install with the latest binary when a new version is available so you get fixes and improvements.
- **Mind retention settings.** Configure how long audit and trash entries are kept to balance accountability with housekeeping.