we-promise/sure: self-hosting the Maybe Finance fork with Docker

Why a fork of an abandoned finance app exists at all

The README is unusually direct about this. This repository is a community fork of the now-abandoned Maybe Finance project. The original team built a full personal finance and wealth management app through 2021 and 2022, including an Ask an Advisor feature that connected users with a real CFP or CFA as part of a subscription. The business did not work out, development stopped in mid-2023, and after spending nearly $1 million on employees, contractors, data providers and infrastructure, the team open-sourced the app. Their stated goal was to let users self-host for free and eventually launch a hosted version for a small fee. That hosted version did launch briefly and also did not work out as a sustainable consumer business. Sure is the fork that keeps the codebase running.

So the audience is narrow and specific. You are a person who wants to track net worth, accounts and transactions, and who is willing to run a Ruby on Rails application on your own hardware rather than pay a subscription. The README lists the ways in: a browser, the macOS desktop app, a mobile app, API clients and LLM agents, with docs/clients.md as the overview. That is a wider client surface than most self-hosted finance tools offer, and it is the strongest argument for picking this fork over writing your own ledger. The weaker argument is stability, which the release list addresses below.

The Rails stack behind Sure and what it asks of your server

Sure is a Rails application, and the repository layout confirms the shape of it: app/, config/, db/, lib/, spec/, plus a Procfile.dev for local process management and a Dockerfile for production images. The Dockerfile pins RUBY_VERSION=3.4.9 as a build argument and tells you to keep that value in sync with the .ruby-version file and the Gemfile. The base image is ruby:$RUBY_VERSION-slim from registry.docker.com, and the first apt layer installs curl, libvips, postgresql-client, libyaml-0-2, procps, libjemalloc2 and poppler-utils. That last package is there for pdftoppm, which the comment says is required for the PDF vision processing path. If you are not feeding statements through an LLM, poppler is dead weight, but it is baked into the image either way.

The build stage is conventional multi-stage Rails: build-essential, libpq-dev, git, pkg-config and libyaml-dev, then bundle install with BUNDLE_DEPLOYMENT=1 and BUNDLE_WITHOUT=development, then bootsnap precompile against app/ and lib/, then assets:precompile with SECRET_KEY_BASE_DUMMY=1 so the build does not need your real master key. The final stage creates a rails user with uid and gid 1000 and runs as that non-root user. The runtime dependencies the README lists for local development are PostgreSQL greater than 9.3 and Redis greater than 5.4, both with the latest stable version recommended. Nothing here is exotic, but it is three services, not one container.

Installing Sure with Docker and creating the first account

The README sends self-hosters to docs/hosting/docker.md rather than giving an inline recipe, and it also links one-click install buttons for PikaPods, Railway and Hostim. If you are running it yourself, start from the example compose file at the repository root. Copy it, then set the required variables from .env.example before the first boot.

cp compose.example.yml compose.yml
cp .env.example .env
openssl rand -hex 64

The third command generates the value for SECRET_KEY_BASE. The .env.example comment states it has to be a random string generated this way, and that it is used to encrypt credentials. Paste the output into your .env. Two more required variables come from the same file: SELF_HOSTED=true, which the comment says should be set to true unless you know what you are doing, and ONBOARDING_STATE, whose valid values are open, closed and invite_only.

SELF_HOSTED=true
ONBOARDING_STATE=open
SECRET_KEY_BASE=<the hex string you generated>

With those in place, bring the stack up with Docker Compose and open the app in a browser. If you want the LLM-backed features, the same file exposes OPENAI_ACCESS_TOKEN, OPENAI_MODEL and OPENAI_URI_BASE for an OpenAI-compatible endpoint, plus a token budget block covering chat, auto-categorize, merchant detection and PDF processing. The comments note you should lower LLM_CONTEXT_WINDOW, LLM_MAX_RESPONSE_TOKENS, LLM_MAX_HISTORY_TOKENS, LLM_SYSTEM_PROMPT_RESERVE and LLM_MAX_ITEMS_PER_CALL for small-context local models such as Ollama, LM Studio or LocalAI, and raise the context window for larger local models. There is a separate compose.example.ai.yml, which is the file to look at if you want the AI path wired up from the start. Developers who want to contribute rather than self-host use a different route entirely: copy .env.local.example to .env.local, then run bin/setup and bin/dev, optionally followed by rake demo_data:default, which seeds a demo account at [email protected] with the password Password1!.

Release candidates are the only thing on offer right now

The most recent releases are v0.7.4-rc.4, v0.7.4-rc.3 and v0.7.4-rc.2, all published within about two days of each other. Every one of them is a release candidate. The README does not document a rollback procedure, does not describe a migration path between release candidates, and does not say whether data written by an rc.2 instance is safe to open with rc.4. For a finance database that is a real gap, and it is the single biggest reason to hesitate.

The repository also carries a .sure-version file and a charts/ directory, which suggests a Helm path exists for Kubernetes users, though the README does not walk through it. The last push to the default branch was on 2026-08-28, the same day as v0.7.4-rc.4, so the project is moving. Moving and stable are different properties, and the release naming makes clear which one you are getting. If your tolerance for re-reading a changelog before every upgrade is low, this is the wrong tool today.

Performance is a known problem, not a hidden one

The README has a section titled Performance Issues that opens with the admission that data-heavy apps inevitably have them. Rather than leave it there, the maintainers publish a Skylight dashboard showing the problematic requests seen on the demo site, with stacktraces attached, and invite contributions that improve performance. That is more transparency than most self-hosted projects manage, and it is also an honest signal: expect slow pages once your transaction history grows. There is a perf.rake task at the repository root, which is presumably how those numbers get produced.

The practical consequence is that you should size your database and your host for growth rather than for the demo dataset. It also means that filing a performance complaint without a stacktrace is unlikely to go anywhere, because the maintainers already have the tooling and have told you where the bottleneck list lives. If you are migrating from a spreadsheet with a decade of transactions, load it in a staging instance first and watch the dashboard rather than assuming the production experience will match the demo.

Sure compared with Firefly III and plain spreadsheets

The obvious alternative is Firefly III, which people search for alongside Sure. Both are self-hosted, both expect a database, and both target the same person who refuses to hand their ledger to a subscription service. The difference is in lineage and in scope. Firefly III was written from scratch as a self-hosted double-entry personal finance manager. Sure is a rescued commercial codebase, which means it inherited product decisions made for a paying consumer audience: net worth tracking, an advisor concept, a macOS desktop app, a mobile app, and now LLM agents as clients. You get a more polished interface and a broader client surface, and you inherit the performance profile and the release-candidate churn of a project that is being rebuilt in public.

A spreadsheet is the other honest comparison. It never breaks on upgrade and never asks for a SECRET_KEY_BASE. It also has no API for LLM agents, no mobile app, and no transaction import pipeline. The decision between them is not about features. It is about whether you want to run PostgreSQL and Redis to get a browser UI, and whether the LLM-assisted categorization is worth the operational cost to you.

Licence, trademark and what a fork may legally call itself

Sure is distributed under AGPLv3, and the README is explicit that the original Maybe Finance code carries the same licence. The AGPL matters for anyone planning to expose a modified instance over a network, because that is the scenario the licence was written for. This is not legal advice, and if you intend to run Sure as a service for other people you should read the LICENSE file and talk to someone qualified.

The trademark rules are clearer and worth repeating because they trip people up. Maybe is a trademark of Maybe Finance Inc., and the README states that use of it is not allowed in forked repositories or in a logo. Sure is not a trademark and refers to this community fork. If you fork this project, the README asks you to include the original AGPLv3 licence and to state plainly in your README that your fork is based on Maybe Finance but is not affiliated with or endorsed by Maybe Finance Inc. The repository also ships a SECURITY.md and a CONTRIBUTING.md, so the maintainers have thought about how contributions and vulnerability reports should arrive.

Editorial conclusion

Adopt Sure if you want the Maybe Finance codebase alive and you are comfortable running a Rails app with PostgreSQL and Redis behind Docker, and if you accept release candidates as your upgrade path. Do not adopt it if you need a stable tagged release, a managed support contract, or a hosted product: the README says the hosted version was launched briefly and did not work out as a sustainable B2C business. Before committing, read docs/hosting/docker.md end to end, check that compose.example.yml matches your server, and confirm what the current v0.7.4 release candidate changes against your running version.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes