Database ownership and proposal

[ild0tt0re]

I saw that with the next updates we will be able to run Organized on our own server with our own database, giving us uncompromised control over all data and access.

Do you have some update?

Proposal

I saw that currently the project use google firebase.
I would like to propose supabase (the open source firebase alternative) as replacement to improve also the local development.

[rhahao]

Hi @ild0tt0re, thanks for reaching out. As of now, this task is not yet started. But Supabase is indeed a good alternative to explore. We will keep this in mind when we start working on that feature. Greetings!

[erykjj]

How is your system up-time? Are down-times frequent and properly alerted?

[rhahao]

Hello @erykjj, good question 😊Since the app is mainly working using local data, I would say it should be ~ 98.99%. If some maintenance has to be done on the server side, and some app features cannot be used, yes indeed, we will send notification to the users. Thank you.

[ux-git]

@erykjj as mentioned, the app works with a local database and not cloud-based, meaning even when down-time will happen, vast majority of features will still be fully usable – even meeting scheduling, PDF exporting, ministry timer and import from jw.org remain functional. Organized is built to not rely on the internet connection. Even for users in areas with poor internet connectivity, having internet access just a few times a week or even a month to sync data from jw.org and update schedules for their congregation is more than enough to then complete all necessary actions.

The only features that will not work during that short period of time are:

1. Data sync (across your devices and within congregation). By default, it happens every 5 minutes, meaning that in most cases the lack of connection won't even be noticed, all the entered data will be synced during the next 5 mins in case of short outages, or immediately after the connection is restored in case of outages longer than 5 minutes.
2. Login. The app won't log users out automatically, but if a user is trying to log in exactly during the outage time, they won't be able to do it and must simply wait a few mins.
3. Collaborative features. Features that require data to be shared with other users, will simply not be visible in the app, while in offline mode. For instance, sending reports to secretary, syncing public talk speakers between congregations, publishing schedules for others in your congregation, and managing roles and settings of other users will be temporarily unavailable. These features are typically used only a few times a month at most, so their temporary unavailability during a short outage will have minimal impact on the overall user experience.

To conclude: Even during downtime, most features will remain accessible, and no entered data will be lost. While some user-to-user features may be temporarily disabled, you can still work in the app without interruption. Once the connection is restored, everything will sync seamlessly.

[erykjj]

Thank you both for the answers. Obviously, no one would want an unexpected outage at monthly report time. So, a solid, well-maintained server is crucial.

Once you implement cart witnessing with daily/weekly scheduling/volunteering/cancellations (or territories), a solid sync is a must, or frustration will ensue.

Thanks again ;-)

[ux-git]

Sure! The app is designed to prevent any loss of information, even in the rare event of an outage. As mentioned earlier, the uptime has been stable and reliable so far.

If you'll have any other questions, feel free to ask 🙂

[Padda-One]

Hi everyone,

I came across this discussion while researching self-hosting options for Organized, and I wanted to follow up since it seems the topic hasn't moved forward since October 2024.

@rhahao, you mentioned back in June 2024 that running Organized on one's own server was planned but not yet started, and that Supabase was "a good alternative to explore." I'd love to know if there's been any internal progress or design thinking on this since then — even rough notes or an architectural sketch would be incredibly valuable for those of us evaluating Organized for privacy-sensitive deployments.

---

On the Supabase suggestion

I want to gently push back on Supabase as the target solution — not because it's a bad project (it's excellent), but because it partially reproduces the same problem we're trying to solve.

If congregations use Supabase Cloud, their data still lives on a third-party US-based server. The sovereignty problem isn't solved, it's just moved from Google to another provider.

Supabase can be self-hosted, but doing so requires running PostgreSQL + a PostgREST API layer + GoTrue auth + a storage server + a realtime engine — that's 5+ moving parts to maintain. For a congregation administrator who isn't a DevOps engineer, this is a significant barrier.

---

An alternative worth considering: a minimal custom backend

Based on my own evaluation, I'd like to propose a simpler alternative: a purpose-built lightweight backend that replaces only the Firebase layer, with a much smaller operational footprint.

The key design goals would be:

• Single binary or single Docker container. One docker compose up and it runs. No database server process to maintain separately.
• SQLite (WAL mode) instead of PostgreSQL. For a congregation-sized workload (tens to low hundreds of users), SQLite is more than sufficient. It means a single .db file — trivially backupable with a cron job or Litestream. No migrations to manage in production, no risk of table corruption after a crash.
• Go or Rust for the backend. Both compile to a self-contained binary with no runtime dependency. Memory footprint under 50 MB. Cross-compiles trivially to Linux ARM (Raspberry Pi, NUC) or x86.
• Caddy as the reverse proxy. Handles TLS certificate renewal automatically. No Nginx config to write.
• Cloudflare Tunnel for external access. No port forwarding, no dynamic DNS. Members connect via a stable HTTPS URL. This is crucial for non-technical administrators.
• Email + password auth only (no Google OAuth dependency). JWT tokens signed locally.

The frontend wouldn't need to change substantially — the self-hosted backend would implement the same API surface currently provided by Firebase, acting as a drop-in replacement.

---

On the offline-first architecture

@ux-git's explanation of how the app handles downtime (most features work locally, only sync and login require the server) is actually a great argument for self-hosting. If the app already works mostly offline, the sync server becomes a thin layer — which is exactly the right fit for a lightweight custom backend rather than a full Supabase stack.

---

Where I stand

I'm a freelance web developer currently in a reflection phase — I haven't written code yet. Before committing time, I wanted to understand whether the core team sees self-hosting as a direction they want to pursue, or whether it conflicts with the project's goals in some way.

If there's openness here, I'd be happy to contribute a proof-of-concept. If the project is moving in a different direction, I'd respect that and consider a separate fork — though collaboration is always preferable.

Thanks again for building this. The offline-first design, the UX quality, and the care you've put into the whole project are genuinely impressive.

With warm regards 🙏

[rhahao]

Hello @Padda-One, thanks a lot for your message and for taking the time to think through this so carefully, I really appreciate it 🙏

Just to share where things are on our side: we haven’t done any work yet around testing or using Supabase.

What we are working on right now is moving away from Firebase step by step. At the moment, we’re focusing on switching from Firebase Storage to an S3-compatible storage. Since this is where most of the app data lives, the goal is to separate this part first before looking at anything else.

For now, authentication is still using Firebase, and there’s no plan yet to move away from it.

Thanks again for sharing your ideas, it’s really helpful to hear different perspectives as the project moves forward 🙂

[Padda-One]

Hi @rhahao, thanks so much for the update — really good to hear the migration is already underway.
The move to S3-compatible storage is actually the most interesting part for self-hosting: MinIO or any S3-compatible endpoint can run in a single Docker container alongside the app, which would already cover the main data layer without touching auth at all.
Quick question if you don't mind: is the S3 migration tracked in a public issue or PR? I'd love to follow along and understand the API surface being used, in case there's a way to contribute or at least build something compatible.
Thanks again for your response ! 😊