Sure: self-hosting the Maybe Finance fork after the original was abandoned

The newest release tag is v0.7.6-alpha.1

Maybe Finance spent most of 2021 and 2022 building a full-featured personal finance and wealth management app, including an Ask an Advisor feature that connected users with a real CFP or CFA. The business end did not work out and development stopped in mid-2023, after nearly $1 million went into employees, contractors, data providers and infrastructure. The team open sourced the codebase, launched a hosted version, and that did not last either. Sure is the community fork that came out of that sequence.

Two facts about the fork matter more than the backstory. The repository is not archived, and the last push was on 2026-11-02. Then read the release names, because they are where the risk sits: v0.7.5-hotfix.3 (Bills, connections, and deeper portfolio insights) was published on 2026-10-24, and v0.7.6 and v0.7.7-alpha.2 both on 2026-10-31. An alpha landing on the same day as a feature release is a fast train. The README does not say which of those tags is safe to pin.

bin/setup and bin/dev after you copy .env.local.example

The README splits setup in two, and the split matters. Anyone self hosting is sent to docs/hosting/docker.md before anything else. The block below is the contributor path, not the deployment path.

cd sure
cp .env.local.example .env.local
bin/setup
bin/dev

# Optionally, load demo data
rake demo_data:default

Copy the example env file, run the setup script, start the development server, and open http://localhost:3000. Three requirements are listed above that block and there is no fourth: the Ruby version named in .ruby-version, PostgreSQL greater than 9.3, and Redis greater than 5.4. If you ran the demo data task, a fixed account is waiting, [email protected] with the password Password1!, so you can read populated records before connecting a single institution of your own.

Frontend checks run through a separate JavaScript stack, and one script there will fail a pull request rather than the app.

		"tokens:build": "node bin/tokens.mjs",
		"tokens:check": "node bin/tokens.mjs && git diff --quiet -- app/assets/tailwind/sure-design-system/_generated.css"

tokens:check regenerates the design system stylesheet and fails when git diff finds an uncommitted change.. What the README does not cover is what to do when bin/setup fails against either database, which sends you to the Mac, Linux or Windows wiki guides on your own.

The image pins Ruby 3.4.9 and needs poppler-utils for PDF vision

There is no docker run line and no compose up line anywhere in the README. Self hosters get a link to docs/hosting/docker.md, two badges for PikaPods and Hostim, and at the repository root only compose.example.yml and compose.example.ai.yml. The first question is whether that linked guide covers the deployment you have in mind.

The Dockerfile shows the runtime's shape even so. It builds on ruby:3.4.9-slim and carries a comment saying RUBY_VERSION must match .ruby-version and the Gemfile, which breaks the build the day you pin a different Ruby.

RUN apt-get update -qq \
    && apt-get install --no-install-recommends -y curl libvips postgresql-client libyaml-0-2 procps libjemalloc2 poppler-utils \
    && rm -rf /var/lib/apt/lists /var/cache/apt/archives

poppler-utils earns its place in that list for a reason the next comment line states: it provides pdftoppm, required for the PDF vision processing path. Strip it to shrink the image and the PDF features lose their renderer. The build also precompiles assets with a dummy secret, which is what lets the image be built on a machine that has no master key.

RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile

The final stage runs as a rails user with uid 1000 instead of root, so any volume you mount for storage has to be writable by that uid or the app will start and then fail to write.

Three Render blueprints, and two of them need an OpenAI token

Render deployment reads a render.yaml at the repository root, and the README explains the wrinkle that trips people up: the branch ready Blueprint files live in branches/<branch-name>/render.yaml in a separate repository, sure-render-templates, and must be copied to each corresponding branch root. The buttons do not read this repository's own branches.

Three targets exist, and they are not cosmetic variations of one build. Sure - No AI deploys the Sure web process, a Sidekiq worker, Render Postgres and Render Key Value, with AI tokens left blank on purpose. Sure - Simple AI adds OpenAI backed AI settings and a pgvector ready Postgres, and Render prompts you for the OpenAI token during the deploy. Sure - External AI substitutes external assistant settings and adds AlphaClaw, which manages the OpenClaw gateway on Render. Each ships a latest and a stable branch, so you are looking at six buttons and no note about which branch the project itself runs.

For someone who only wants their own balances, the No AI blueprint is the one to read first. Simple AI costs you an OpenAI token you supply, and External AI adds a second moving part, AlphaClaw managing the OpenClaw gateway; the README does not walk through configuring either.

SELF_HOSTED and ONBOARDING_STATE gate the signup form

Before any finance code runs, .env.example fixes the terms of access. The file describes itself as an outline of all the possible environment variables supported by the Sure app for self hosting, and the required set is three lines long.

SELF_HOSTED=true
ONBOARDING_STATE=open
SECRET_KEY_BASE=secret-value

ONBOARDING_STATE accepts open, closed or invite_only, which means a self hoster can hold registration shut from the first boot rather than discovering after launch that anyone who found the URL can create an account. SELF_HOSTED is documented as something to set to true unless you know what you are doing, and it is the switch that enables the self hosting features at all.

SECRET_KEY_BASE is the one to treat carefully. The file labels it the secret key used to encrypt credentials and suggests generating it by running openssl rand -hex 64. Because the key is used to encrypt credentials, treat changing it after deployment with care; the README names no procedure for rotating it.

One LLM budget covers chat, auto-categorize, merchant detection and PDFs

The AI features draw on a single set of caps, and .env.example says which features spend it: chat, auto-categorize, merchant detection and PDF processing. The commented defaults are small.

# LLM_CONTEXT_WINDOW=2048
# LLM_MAX_RESPONSE_TOKENS=512
# LLM_SYSTEM_PROMPT_RESERVE=256
# LLM_MAX_ITEMS_PER_CALL=25

A 2048 token context window decides your experience if you copy those lines as written, and LLM_MAX_HISTORY_TOKENS has no value in the file. LLM_MAX_ITEMS_PER_CALL=25 bounds how many records a single categorization or merchant detection call will look at. The file tells you to lower the caps for small context local models such as Ollama, LM Studio or LocalAI, and to raise the window to match larger local models, naming Gemma 3/4 and Qwen as ones that often need LLM_CONTEXT_WINDOW=8192 or higher.

Three keys decide whether any of this runs at all: OPENAI_ACCESS_TOKEN, OPENAI_MODEL and OPENAI_URI_BASE, all empty by default. Leave them empty and the AI paths have nothing to call, which is the state the No AI Render blueprint deliberately ships.

A slow request dashboard instead of a performance claim

The performance section concedes the problem rather than defending against it: with data-heavy apps, inevitably, there are performance issues. It links a public Skylight dashboard showing the problematic requests seen on the demo site along with their stacktraces, and invites contributions aimed at them.

That is a useful posture and a weak promise. The dashboard describes the demo instance running the fork's own data, and it gives you no throughput, latency or memory figure for a dataset of your own. No target is stated, and the README publishes no benchmark. What is in the repository is a perf.rake task at the root, though the README does not name the task to invoke.

The consequence is that you cannot size your machine before installing. The dashboard is a debugging thread, not evidence that a modest host will keep up.

Fire-Fly III starts from a ledger, Sure starts from a client list

People line Sure up against self hosted managers such as Fire-Fly III, and the gap is structural rather than a matter of polish. Fire-Fly III is built around double entry bookkeeping, so accounts and journals come first and an interface sits on top. Sure descends from a wealth management product, and the repository is organised around the surfaces it serves: a browser app, a macOS desktop app under desktop/, a mobile app under mobile/, API clients and LLM agents, with docs/clients.md as the map.

That difference decides who each one fits. Want the books to be the source of truth and willing to live inside an accounting model, and a ledger first tool is the more natural home. Want a portfolio view that also answers questions from a phone, a desktop or an agent, and Sure has already built those surfaces.

Picking the fork carries a licensing consequence worth stating. Both projects are AGPLv3, and that licence attaches to network use, so a self hoster who modifies Sure and serves the result has to publish the change. The README also requires any fork to keep the original license, say that it is not affiliated with or endorsed by Maybe Finance Inc, and drop the Maybe name and logo, both of which are trademarks. A quietly patched private build fits neither rule.

Editorial conclusion

Sure fits a reader who wants a portfolio app with macOS, mobile and agent clients and is willing to run a community fork whose newest tag is an alpha. It does not fit anyone who needs a support contract, a stable pin, or a ledger first accounting model. Check two things before you commit: read docs/hosting/docker.md, because the README defers the whole self hosting path to it, and set ONBOARDING_STATE to closed or invite_only before the first boot, not after you have opened the URL to the internet.

Frequently asked questions

Official sources

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