Trust center · reviewed August 1, 2026

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.

The operator controls the browser, app, and PostgreSQL database; outside requests can reach GitHub updates, chart assets, optional Turnstile, and certificate services.
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.

DestinationWhen it is usedWhat leaves the installOperator control
GitHub Releases APIThe 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.
jsDelivrChart.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 TurnstileOnly 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 servicesThe 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.