# Habo Habit Tracker: E2EE Sync and Self-Hosting > Habo is an open-source Flutter habit tracker for iOS and Android, with offline tracking, end-to-end encrypted sync, and optional self-hosting through Supabase. It fits users who want local habit records without requiring an account, but the server setup and encryption model require careful review before adoption. **xpavle00/Habo** — Privacy-first habit tracker for iOS and Android. E2EE sync, self-hostable, built with Flutter. - Repository: https://github.com/xpavle00/Habo - Website: https://habo.space - Stars: 1,544 · Forks: 181 - Language: Dart - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/xpavle00-habo ## Habo's account-free habit tracking model Habo addresses a narrow but common problem: recording repeated routines without turning those records into a mandatory cloud account. The README says the application requires no accounts and works offline, so the core tracking path does not depend on Habo's hosted service or a self-hosted server. That makes it relevant to users who want daily check-ins on iOS or Android while retaining control over when network access is used. The application supports yes-or-no completions, numeric entries, and skips that do not break a streak. Each check-in can also include notes. A calendar view displays completions and streaks on a monthly grid, while statistics summarize streaks, trends, and completion history. Reminders, categories, drag-and-drop ordering, archived habits, and dark, light, and OLED themes cover common tracker needs without turning Habo into a general productivity suite. This account-free statement applies to the habit-tracking model, not automatically to every optional integration. The repository's `.env.example` contains configuration for Supabase, Google Sign In, and RevenueCat. The README documents Google Sign In only as part of configuration for development, and it does not explain which hosted feature, if any, currently requires authentication. Potential users should not assume that the presence of those variables means every feature requires an account. Habo is therefore most directly aimed at people who want a mobile-first tracker with local use and optional encrypted synchronization. It is not presented as a team collaboration product, a web dashboard, or a habit-coaching service. The project describes itself as minimalist, and its feature list stays centered on logging, reviewing, and retaining routines. ## What Habo 4.0 encrypts before synchronization Habo 4.0 adds cross-device synchronization, automatic encrypted backups, and support for a self-hosted Supabase backend. According to the README, habit data is encrypted on the device before upload using a Master Password. The server receives ciphertext rather than readable habit records, notes, or streak information. The project describes this arrangement as zero-knowledge and says plaintext never reaches the server. The repository also lists device-generated encryption keys as part of the sync design. The README does not fully describe how those device keys are created, transferred, wrapped, rotated, or recovered. It also does not explain in detail what happens after a user forgets the Master Password, loses every enrolled device, or changes an account's credentials. Those omissions matter because encrypted storage can prevent server operators from recovering inaccessible data as well as protecting it. The stated data path has four clear stages: a habit check-in is created in the local application, the relevant data is encrypted before leaving the device, the backend stores ciphertext, and another enrolled device can use encrypted backups for synchronization. The Supabase deployment adds a controllable backend, but it does not by itself make the mobile client trustworthy. Client code, database migrations, the `delete-account` edge function, key handling, and deployment configuration remain separate review points. This design is attractive when server-side plaintext access is unacceptable. It is less convenient when an organization wants an administrator to recover records, inspect synchronization activity, or restore an account without the original encryption credentials. Habo makes a strong privacy claim, but adopters still need concrete documentation for recovery and key lifecycle behavior before placing especially sensitive notes in the tracker. ## Installing Habo for a first Flutter run The simplest documented development path requires Flutter 3.x, the Dart SDK bundled with Flutter, and either Android Studio or Xcode for device targets. Clone the repository, resolve Dart packages, and launch the application on an available target. ```bash git clone https://github.com/xpavle00/Habo.git cd Habo flutter pub get flutter run ``` The README does not document the exact output of `flutter run` or a specific emulator setup procedure. A successful command should attach Habo to an available Flutter target; the repository's `android/`, `ios/`, `linux/`, and `macos/` directories indicate the expected platform layouts. If no target is configured, the reader will need to resolve that through Flutter and the platform-specific tool before proceeding. For ordinary mobile use without building from source, the README links to Google Play, the App Store, and IzzyOnDroid. It does not provide release-specific installation commands or explain the distinction between the regular `v4.0.0` release and the `v4.0.0-foss` release. That distinction should be checked in the relevant store listing or release notes before selecting a distribution. After launch, the first useful workflow is to create a habit, choose the appropriate completion type, perform a check-in, and review it through the calendar or statistics views. The README does not document the exact menu sequence for creating that first habit, so this tutorial does not invent interface labels that are not provided. ## Configuring Habo Sync on a private Supabase backend Habo Sync can use a self-hosted Supabase backend without a subscription. The documented prerequisites are a Supabase account and Node.js for the Supabase CLI through `npx`. The free tier is described as sufficient. Link a local Habo checkout to an existing Supabase project with the documented project reference placeholder: ```bash git clone https://github.com/xpavle00/Habo.git cd Habo npx supabase link --project-ref ``` Next, apply the repository's database migrations and deploy the named edge function: ```bash npx supabase db push npx supabase functions deploy delete-account ``` After both commands complete, open `Settings → Server` in Habo. Paste the Supabase Project URL and anon key, then tap `Test Connection & Save`. The README does not state the location from which those values should be copied, so operators must obtain them from their own Supabase project. `.env.example` also accepts plain or Base64-encoded forms for `SUPABASE_URL` and `SUPABASE_ANON_KEY`, but the application setup instruction in the README calls for entering the URL and anon key in the app. This route moves hosting responsibility to the adopter. It exposes additional operational concerns: database migration execution, edge-function deployment, endpoint configuration, backup handling, and future compatibility between client and backend versions. The `supabase/README.md` file is identified as the source for full details and troubleshooting, which indicates that the main README does not cover the complete operational procedure. ## Habo's privacy benefits and recovery trade-offs Habo's main advantage is the separation between local usability and remote storage. Offline-first operation means habit logging does not stop when connectivity fails. Automatic encrypted backups then provide a route to retain history when replacing a phone. Biometric locking adds a local access barrier using Face ID, Touch ID, or passcode, while export and backup features are presented as alternatives for retaining ownership of records. These controls address different threats. Biometrics protect access through the device interface. End-to-end encryption protects data from plaintext exposure by the synchronization server. Self-hosting changes who operates that server. None of these facts establishes how a forgotten Master Password is recovered, how a new device receives the necessary key material, or whether an export can be imported into a replacement installation. The README calls backups automatic but does not document rollback or restore semantics. Habits can also contain sensitive information even when the application is described as minimalist. Notes and comments may record health-related routines, locations in habit names, or personal reasons for tracking a behavior. Encryption before upload limits server-side plaintext exposure, but adoption decisions should still include device security, application updates, export retention, and account recovery. The project is not archived, and its last push was on 2026-10-14. The recent release history includes `v4.0.0-foss` on 2026-10-02, `v4.0.0` on 2026-05-06, and `v3.1.2` on 2026-02-22. Those facts indicate recent development activity, but they do not reveal migration compatibility between versions. Users upgrading across the 4.0 boundary should check release notes before importing an established habit history. ## Choosing Habo against a conventional habit service A conventional cloud habit service commonly centers synchronization on a provider-managed account. Its operator can generally associate an account with records, administer the service, and provide recovery paths because it controls the relevant data and authentication systems. Habo takes a different approach: local operation remains available without an account, client-side encryption is applied before upload, and a self-hosted Supabase deployment can replace the hosted backend. The practical difference is control, not merely branding. With Habo self-hosting, the person deploying the backend owns the Supabase project, migrations, edge function, endpoint configuration, and operating process. That can fit a technically capable user who wants direct control over hosting. It also transfers responsibility for backups, monitoring, updates, and troubleshooting to that user. A managed service may be easier when recovery support, predictable administration, or a smaller infrastructure footprint matters more than operator control. The README does not document service-level commitments, hosting-region details, or a recovery process, so this comparison cannot be extended into a claim that Habo is more reliable or less reliable in those areas. The GPL-3.0 license also affects distribution and modification. It provides the stated basis for open-source use, modification, and redistribution under the license's terms. The README also calls Habo auditable and forkable, but organizations still need to account for their Flutter, Supabase, distribution, and proprietary integration components separately. This is a compliance consideration rather than legal advice. ## Conclusion Habo is suitable for users who want a focused mobile habit tracker, can operate its offline model, and are willing to manage a Supabase deployment or accept a hosted sync dependency. It is a weaker fit for people who require a documented recovery process, a web-first interface, or an independently verified explanation of every encryption-key transition. Before adoption, verify whether the v4.0.0-foss distribution covers the required Flutter targets, confirm what users can inspect in `supabase/README.md`, and test master-password loss and device migration against the consequences you can accept. For projects where the meaning of encrypted sync is the deciding factor, inspect Habo's key-management documentation and deployment files first. ## FAQ ### Does Habo require an account to track habits? The README says no accounts are required and that core tracking works offline. Optional sync introduces Supabase configuration, but the documentation does not say that every habit-tracking feature requires an account. ### Can Habo be self-hosted? Yes. Habo documents a self-hosted backend using Supabase, with database migration and edge-function deployment through the Supabase CLI. ### What happens if I forget Habo's Master Password? The README does not document recovery after a forgotten Master Password. Since data is encrypted locally before upload and the project describes a zero-knowledge model, users should not assume the synchronization server can recover the plaintext. ## Sources - [License: GPL-3.0](https://github.com/xpavle00/Habo/blob/master/LICENSE) - [Project website](https://habo.space) - [README](https://github.com/xpavle00/Habo/blob/master/README.md) - [Releases](https://github.com/xpavle00/Habo/releases) - [xpavle00/Habo on GitHub](https://github.com/xpavle00/Habo) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xpavle00-habo