The System section in Settings contains app-wide configuration options that affect how Dosh calculates and displays budget data.

Dosh uses a weekly budget period. By default, weeks run Sunday–Saturday. You can change this to Monday–Sunday here.

This affects:

• Which day the Budget page considers the start of a week
• Which weekly transactions are included in a category's "Spent" total
• Week navigation arrows on the Budget page

Changing the week start day takes effect immediately. Historical budget views will reflect the new week boundaries retroactively.

When enabled, budget calculations (such as weekly equivalents and catch-up) update dynamically based on the current date rather than the start of the week. This keeps planning figures accurate throughout the week rather than only recalculating at week boundaries.

All users can see the user list. Creating additional users is done from the Settings page.

Click New User, enter a username and password. The new user can log in immediately.

All users have the same level of access — Dosh does not have role-based permissions. Every user can view and modify all accounts, transactions, budgets, and settings.

Passwords can be changed from the Settings page by any user.

If a user is locked out and cannot log in, use the CLI reset script to reset their password directly against the database:

Development:

cd backend && npm run reset-password -- <username> <newpassword>

Docker (production):

docker exec -it dosh node /app/backend/dist/scripts/resetPassword.js <username> <newpassword>

The script invalidates all existing sessions for the user, forcing a fresh login.

All actions in Dosh are recorded in an audit log. To view the audit trail, go to Audit in the sidebar. The log shows:

• Date and time
• Username
• Event type (e.g. transaction created, budget updated, user login)
• Entity affected (account name, category name, etc.)
• Client IP address — the IP of the device that performed the action

The audit log is read-only and visible to all users.

Failed login attempts are recorded in the audit trail. Each failed attempt logs the username that was used and the client IP address, making it possible to detect brute-force or unauthorised access attempts.