Know exactly what the app protects—and what remains your job.
Your budget lives in the PostgreSQL database you operate, and the app does not ask for bank-link credentials. Protect the host, access, updates, and backups.
Your installation holds the records. Review and control the network paths around it.
Data boundary
Your installation holds the financial records.
Stored in your PostgreSQL database
User records and authentication data.
Budget months, recurring templates, entries, and notes.
Manual accounts, snapshots, linked activity, and import records.
Preferences, release state, and administrative audit records.
Not provided as a FinanceTracking.app cloud account
There is no hosted FinanceTracking.app SaaS database.
The product does not automatically connect to financial institutions.
The project does not receive a copy of your self-hosted database or application export.
Server logs, infrastructure snapshots, and off-host backups remain under the operator's chosen providers.
Important distinctionThe public marketing website uses Google Analytics. That website measurement is separate from a self-hosted FinanceTracking.app installation and cannot read the records in your database.
External-request inventory
The app is self-hosted, but it is not a no-egress product.
Destination
When it is used
What leaves the install
Operator control
GitHub Releases API
The app checks for a newer release and caches the result.
Request metadata, repository name, app version in the user agent, and the host's network address. No budget records are sent.
Set GITHUB_UPDATE_CHECKS_ENABLED=false to disable the check.
jsDelivr
Chart.js and Apache ECharts load in the browser on pages that render charts.
A normal browser asset request, which can include IP address, browser details, and referrer information.
Block the CDN at the network or browser level, understanding that chart surfaces may not render.
Cloudflare Turnstile
Only when the operator configures both Turnstile keys for authentication protection.
Browser challenge and verification data handled by Cloudflare.
Leave both Turnstile variables unset to keep the integration disabled.
Caddy certificate services
The included public-production proxy obtains and renews trusted TLS certificates.
Domain and certificate-validation traffic required by the configured certificate authority.
Choose a different reverse proxy or the documented private-LAN certificate path.
Included controls
Security features are useful layers, not a substitute for operations.
Authentication boundaries
Regular users and administrators use separate sign-in surfaces. Administrative access manages users and audit history without exposing private budgeting records.
Abuse resistance
Public authentication routes are rate limited. Operators can also enable Cloudflare Turnstile when that external dependency fits their deployment.
Browser protections
The application sends a restrictive Content Security Policy, rejects framing, limits approved script and frame sources, and upgrades insecure requests outside development and test.
Production HTTPS defaults
The production configuration assumes TLS termination, forces HTTPS by default, uses secure cookies, checks allowed hosts, and keeps Rails and PostgreSQL inside the Compose network.
Automated checks
Continuous integration runs Ruby static analysis, gem vulnerability checks, importmap dependency auditing, tests, and system tests. Passing scans reduce known risk; they do not prove the absence of vulnerabilities.
Encryption and recovery
Protect both the live database and every copy made from it.
Application backups
Exports are versioned JSON. A user can optionally protect an export with password-based authenticated encryption, and the restore flow previews supported changes before applying them.
An encrypted export is still only as safe as its password and storage location.
Infrastructure backups
Database-at-rest encryption, disk encryption, filesystem snapshots, remote backup storage, retention, and restore testing depend on the host and providers selected by the operator.
Keep PostgreSQL backups as well as application exports; they solve different recovery problems.
Operator checklist
Before exposing the app, make these decisions explicit.
01
Pin the release
Choose a specific published image tag and review release notes before updating.
02
Set real secrets
Use unique Rails, database, admin, and user credentials; never commit the production environment file.
03
Limit access
Configure HTTPS, allowed hosts, registration policy, firewall rules, and host administration for the intended audience.
04
Back up two ways
Keep PostgreSQL/infrastructure backups and portable application exports in controlled locations.
05
Practice recovery
Test restore steps away from the important installation before depending on a backup.
06
Review outbound requests
Disable optional integrations or restrict network access when their tradeoff does not fit your environment.
Found a security problem?
Keep the report private and use fabricated data. The security policy explains scope, useful report contents, and the information that should never be sent.