Pocketbase lost its funding from FLOSS fund

There was an error while loading. Please reload this page.

FLOSS/fund reached out to me again but due to some unforeseen regulatory constraints their partnership with GitHub didn't seem to work out. Instead they want to issue a wire transfer from India requiring several cross-jurisdictional paperwork but I don't feel comfortable doing that because I don't trust them, nor the India government, with processing and storing personal sensitive data (especially over insecure shared mail inbox channel).

So in the end I had to withdraw my FLOSS/fund application and decline the funding.

I've made a mistake for not researching it more carefully and not waiting for the disbursal before making big announcements and decisions, but it is what it is.

Nonetheless the main goal remains and I'll try to publish a stable PocketBase version this year (no hard promises though; the majority of the new UI functionality is already implemented but I'll have to look for something else in between before making more elaborate plans regarding the remaining tasks).

There will be a new announcement once I have more clarity and readiness to request community feedback.

I'll go ahead and lock this discussion to avoid further spamming the participants and repository watchers.

I am happy to announce that yesterday FLOSS/fund contacted me about their decision to sponsor PocketBase as part of their second funding tranche. You can find more details and the other cool projects they've chosen to support at https://floss.fund/blog/second-tranche-2025-anniversary/.

> Note that FLOSS/fund and Zerodha are planning to continue with the program next year, so if you are looking for a no strings attached sponsorship for your open source project, I encourage you to apply at https://dir.floss.fund/submit.

With the funding this means that starting from December I'll be able to work solely on PocketBase for at least one year, with the general goal to finally have a stable PocketBase release by end of next year. My short-term focus for now will be on rewriting the UI.

One of the biggest limitations of PocketBase right now is the lack of dashboard customization.

While you can create server-side plugins using the existing app event hooks (ex. the JS pb_hooks are implemented as such; see also a recent community project posted in #7273), there is no mechanism at the moment to extend the UI for things like: adding custom options to existing fields, registering new fields, customizing the settings and what is shown when in "production" mode, registering new OAuth2 providers, registering new system sections (see #7232), etc.

Usually this shouldn't be a difficult task considering that the dashboard runs entirely in the browser and loading HTML/JS/CSS dynamically is what browsers are good at, but the goal is NOT to just inject some extra assets on the page because this wouldn't really work for many of the highlighted issues above, or at least not for what I plan to use the UI plugins for.

Ideally we should be able to interact with the SPA router and the various reactivity states of the dashboard from an external script. And this unfortunately is very difficult to be implemented when using a compiler framework like Svelte because we'll have to force on everyone an additional UI Node.js build step when extending PocketBase and I want to avoid that.

I've explored other more runtime/dynamically-friendly frameworks like Vue, Preact, Lit, Solid, Alpine, Mithril, and technically any of them will do the job (Vue or Lit will be my preference) but they have their own DSL that often doesn't play nicely with other frameworks and most importantly I don't feel confident that I'll be able to maintain them on my own in case they decide to do a major refactoring, change the direction or abandon their project.

My main goal with PocketBase is that once we hit a stable release, I'll mark the project as "complete" and new changes or features will be added very rarely and most likely will follow the bi-annual Go release cycle, aka. the less dependencies we have the better.

So with that in mind, the last couple weekends I've been experimenting with a new frontend framework designed around with the minimal functionality required for PocketBase.

It is called Shablon (https://github.com/ganigeorgiev/shablon), it has 0 dependencies and it is written in plain JavaScript. I'll try to keep it as simple as possible and without the concept for "component" so everything ideally will be plain DOM elements sprinkled with optional reactivity (a "component" could be just a function that return a DOM element, no matter whether it was created using the t.[tag](attrs, ...children) helper or document.createElement(tag)).

It is certainly not as ergonomic and pretty as something like Svelte, but I believe it would be better suited for our purpose.

In the worst case if it turn out too ugly and inefficient, I'll just go back to Vue or Lit but for now I'm planning to continue experimenting with it.

I've also already started working on a new PocketBase UI kit for reusable elements like fields, buttons, popups, dropdowns, alerts, etc.

So that's it for now. Most likely sometime next week (or the week following it) there will be another announcement for an eventual minimal breaking change with the experimental relation filter resolution as subqueries but other than that, the project will enter a temporary "feature freeze" until I have something more concrete to show related to the UI (I want to take my time with it and don't want to rush it, so please be patient).

Thanks once again to FLOSS/fund and @zerodha for supporting the project!

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Really cool - great to hear! BTW you might want to take a little bit of inspiration from my library called nano signals that I made for a YT demo, which basically kind of like the vanilla version of Svelte 5 and I think accomplishes the same thing. Feel free to re-use any code from it. I think there is a lot more that goes into doing signals properly, but it works, and it might give you some ideas.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Thank you but I'm satisfied with the current Proxy approach of the store implementation and for now I'm not planning changing it (the pattern is very similar to what people nowadays refer as "signal").

The only thing that still bothers me slightly (and it is yet to be tested how it will perform with deeply nested tags) is the global MutationObserver required for the lifecycle functions (onmount, onunmount) as I couldn't find a way how to do it properly (I didn't want to introduce a special component wrapper structure) but the approach will be evaluated during integration.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

The way to get around the problems of global MutationObserver is to use shadowdom with each component having its own one.

I recommend that you look at ponys (not my project). It's a good base for vue-like and svelte-like components. There is nice simple code there with a lot of eyeballs on it. You can mount any element in the template for your Shablon approach, and style and script tags can be written as normal. Put the Shablon function as a render function, or something like that.

I'll have to step up the release of my framework so that it can at least be seen. How will people include their own themes for components that doesn't crash with other people's themes? Instead of all of that trouble they could just put it in a style tag. This approach allows components to be inlined or async downloaded. If you look at ponys you'll see that it's leveraging many evergreen browser technologies.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

The way to get around the problems of global MutationObserver is to use shadowdom with each component having its own one.

I don't see why would you need a shadowdom for that. A custom Web Component wrapper usually is more than enough to make use of its lifecycle callbacks but as mentioned above I want to avoid having a special "component" structure and prefer working with native DOM elements. This also will allow people to "plug" their own framework of choice if they want. Note also that I've also explored in the past internal wrapper with the is attribute but this doesn't work on Safari. For now the MutationObserver approach seems to perform fine when inserting and deleting 10k nodes each with 3 children and at least based on that tests it didn't have noticeable impact on the performance.

How will people include their own themes for components that doesn't crash with other people's themes?

There are no plans to introduce scoped CSS if that's what you are asking. We'll have a documented UI kit but for the cases where users want to provide their own CSS they can simply prefix their classes with something unique to their plugin and bind their CSS based on that prefix.

If you look at ponys you'll see that it's leveraging many evergreen browser technologies.

I'm aware of Ponys but I don't find it ergonomic enough to work with and if we were going to use web components then I would just use Lit to be honest.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Super happy for you! Can't wait to see what you do with the UI!

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Love this for you and for us!! Excited for the continued development of Pocketbase and all the new features to come! Thanks for continuing to put time and energy into the project.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Huge congrats Gani

Thanks for this awesome project, PocketBase is amazing and this money is so well deserved

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

That's awesome Gani! Congrtatulations!

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Congratulations and look forward to seeing what's next for pocketbase! 👏👏

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Lets gooo! Congrats Gani

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

happy to hear that, congrats! 🥳

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Amazing news! Congrats. 🎉

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I'd personally advise against creating your own front-end and UI frameworks, as it can slow down development. Leveraging existing ones is generally much more efficient. That said, I support your decision either way!

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

They stated that they want zero dependency and required minimal maintenance, current ui framework is release very often and sometime break things

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Congrats! Absolutely looking forward to see what the future of pocketbase holds, it's been one of the most incredible and useful tools I have used and it is absolutely amazing to see it get the love it deserves.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

OK, I think this discussion is starting to resemble the ones from back in #4355. I'm thankful that you want to help, but I'm not seeking suggestions for a frontend framework and I'll appreciate if people stop spamming me with their preference.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Amazing, congrats, well deserved!! Best of luck Gani. Please keep it lean and simple.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Cool, congratz!

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

@ganigeorgiev congrats! 👍

One of the biggest limitations of PocketBase right now is the lack of dashboard customization.

I periodically monitored user issues. These mostly concerned scaling/authorization via external services, as well as the lack of tools like a SQL editor/Presence API. Also, the documentation for JSVM was unclear—some areas weren't described, and the problem could only be solved by rereading GitHub or the system code itself.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

If you have suggestion for anything specific, feel free to open a Q&A discussion but many of the "issues" that you've mentioned were discussed several times already and most of them could be handled via the existing app event hooks (for example, presence was discussed several times but the problem with who should have access to that information, how it should be structured (rooms, groups) and how it should work were never really generalized enough to make sense to have it builtin; it just vary too much from one use case to another and it is better left to the developers to handle on their own).

The UI rewrite is prioritized because it is practically hardcoded and there is no option at the moment (without forking the project) to customize the default behavior. That's not true for the backend part.

The documentation will definitely be improved once the APIs stabilize.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Ok. Thanks. I know some of the issues have been discussed, so I thought I'd summarize them. But these issues did not go beyond discussion. I've seen a few examples where PocketBase was used simply to store a single table (like a book), and the developer used it exclusively as a CRUD engine. But I don't think your program was intended as a simple CRUD engine. For larger projects, you'll need additional capabilities (again, if you follow principles like self-contained, simple, and extensible). So, we simply take any application—say, a simple online chat—and look at what's missing for implementation, and it turns out that to write a chat, you need the ability to retrieve a list of online users. And then from this another question arises: how to do it and where to store it. By closing the presence api implementation, you solve 90% of the problems of standard web applications at once.

Again, you've done a great job with the engine, and there's no point in trying to force my opinion on you. But answer the question: who needs Pocketbase/what for, and what skills does someone need to have to work with it?

Once again, congratulations on the grant. I hope you find time not only to work but also to relax.🎉🎈

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Maybe there is a language barrier and my English is just bad, but I honestly don't understand the purpose of this comment and how it is related to the announcement, so I'll stop engaging further but will try to address some of it.

and it turns out that to write a chat, you need the ability to retrieve a list of online users.

Again this is not as simple to solve as you may think because it highly depends on your specific use case (for example the groups/rooms requirement). Unfortunately I can't explain it better than what has already been discussed (I think the most recent one related to this topic would be probably #5101).

who needs Pocketbase/what for, and what skills does someone need to have to work with it?

I'm not here to try to sell you anything. PocketBase was created primarily for my own use case (please read the FAQ) which just happens to be generic enough so that other users can also use it. If by reading the documentation you don't see why you may need PocketBase, then you shouldn't use it. There is no point to sugarcoat it.

This is just a hobby non-commercial open source project and it will remain such. The grant will help accelerating the development process but it doesn't change the direction or scope of the project.

Again, if you have suggestion or a blocker issue that you would like to be addressed, free free to open a Q&A discussion but try to be more specific about your use case so that me and other users eventually can assist you.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

u don't see why you may need PocketBase, then you shouldn't use it. There is no point to sugarcoat it.

This isn't about me. I just wanted to raise the most active topics in hopes of including them in the pocketbase. But based on your responses, I already understand what the development priorities will be on current stage.

This is just a hobby non-commercial open source project and it will remain such.

I think everyone already understood this. You mention it in almost every topic. 👍😁

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Congratulations on the sponsorship and I hope you develop Pocketbase to what you want it to be. I've been following the project for about a year and i used it a few times. I love that you are responsive in the discussions and you dont tolerate PRs that dont make any meaningful contributions. I hope one day, you open user donations to the project once again.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I’d have preferred that you've used the funds on actually improving PocketBase and not to create another JS framework... 😕

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

It’s entirely up to Gani to decide what to build and how to use the funds. He’s made it very clear that this is a hobby project, and he doesn’t owe anyone an explanation or justification. It exists to solve his own problems.

That said, PocketBase has gained so much traction that it’s natural for many people to have opinions, requests, and expectations. I agree with you, I also wish the project had taken a different direction or the community would have been involved slightly more.

Still, Gani is completely within his rights to run it as he sees fit. Secretly though, I hope that one day he’ll consider involving others so it doesn't feel like a one-man project anymore, simply because his fantastic framework has grown far bigger than he probably ever expected thousands rely on it. Again, not because he hasn't been clear, but because reality has changed things.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Gani stated his reason pretty clear what he want in that repo

... Since I didn't feel comfortable maintaining UI plugins system on top of another framework with dozens other dependencies that tend to change in a non-compatible way over time, I've decided to try building my own with minimal API surface and that can be safely "frozen".

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I think there is some misunderstanding (with hindsight, maybe it wasn't a good idea of me combining the funding announcement and the UI rewrite decision into one).

The work on the UI rewrite has been going on for several weekends already (this includes Shablon) and it has no relation to the funding, it is just a happy coincidence.

The UI rewrite is not really avoidable if we want to have full-featured plugins support, aka. to be able to extend both the frontend and backend part of the application.

Addittionally note that Shablon is already 90% complete and there is nothing really much to it. If you ignore the jsdoc comments and tests, the source code is probably less than 600 loc, which is practically nothing.

Again, the framework will have only the minimal required things that what we need for PocketBase, there are no plans to add more features to it.

I've mentioned this previously, but will repeat my self again - the funding will help significantly speed up the development process (without it I was planning maybe a stable release for mid 2027/28) but PocketBase existence doesn't really depend on it or even on the number of users using it. In the end of the day it is primarily a hobby and it will continue to exist as long as I have use for it and I find it interesting to work on. I know that this is not very community friendly but I don't think I'll be able to manage it otherwise, so please adjust your expectations.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Will it be like on Directus, where different types can have X different interfaces (e.g a TEXT field could be an inline input, or a rich text field, or a codeblock, etc.)?

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I'm not entirely sure that I understand what you are referring to but there are no plans to have different multiple visualizations in the dashboard for the existing fields out of the box.

The main difference with the new version ideally would be that users will have the option to extend the default functionality and either define a new field with its own completely different UI rendering OR modify the rendering of the existing fields (option to store arbitrary data, e.g. "meta", as part of the collection and fields configuration will be considered as it was requested several times already).

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I understand, so it is somewhat similar, and I like it. I'll contribute when it's released.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Great news

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Congratulations.

I really love PocketBase, there isn't anything like it right now.

Can't wait for the stable release, hopefully it always stays tiny, self-sufficient and easy to use.

However I wouldn't say no to external DB support, more Auth goodies and more official SDKs.

Good luck man.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Huge congrats @ganigeorgiev 🎉 The funding is well deserved and can't wait for the stable release!

We also appreciate the PocketBuilds shout out:

We were actually working on a Templ/HTMX rewrite to allow Admin UI overrides because we thought it would enable more Plugin options for us. Here's our WIP in case anyone finds it interesting or useful: https://github.com/pocketbuilds/admin_ui

Very excited for the new UI rewrite! Shablon looks awesome!

Edit: If this wasn't clear, we're planning on abandoning our approach in favor of the officially supported option. Just wanted to drop the reference in case it was helpful for Gani to see what other folks were trying, or if other Templ/HTMX users wanted to use it as a model for their own projects.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

🎉 congrats Gani truly well deserved! Just finished migrating to 33 and love the new hooks. One minor suggestion for the new UI if I could make - could you add a thin line at the top that can be changed from the settings and set to green on prod?

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

I don't understand. What would be the benefit of this "thin line"? To make it more clear that it is the prod environment?

If that's the case then I don't think it would be necessery because the new UI will have a colored frame around the main app content and users will be able to select a "theme" for their app (there will be 3 or 4 builtin themes each with light and dark variants). I'm not sure how to explain it better but here is part of a very rough mockup (I don't want to share more details as it is still very much work in progress and most likely will change during integration):

Note also that there are plans to add a more general "PROD mode" which will supersede the current "Hide collection create and edit controls" + may require extra confirmation when changing app settings (or when editing records).

If you have other suggestions, please open a new Q&A discussion with more details about you use case to avoid spamming all participants.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

FYI, if your deployed instance has a valid SSL certificate (which is likely for production environments), the PB favicon will be green.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Thanks, just noticed the icon change 🙏

To make it more clear that it is the prod environment?

Exactly sorry for not being clear. Your idea is even better 🚀

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

LETS GOOOO!!!

.　 (⌒⌒⌒)

|＿＿_|

(´・Д・`) 　　 ⊂ﾆ⊃

（　　ｏO━ヽニニフ ))

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Once pocketbase hits stable release will there will be any migration guide for people using versions <=0.22?

Bdw, congrats on the funding. ^_^

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

There will be a migration guide but it will cover upgrades only from the last couple PocketBase versions before the new release.

For devs that want to upgrade and that are still using <=v0.22.x it will be recommended to try to upgrade first to v0.23+ following the CHANGELOG and the linked migration guides. While I try to keep breaking changes minimal, big jumps between versions may not always work and you'll have to take extra care for "⚠️" marked items and upgrade on smaller steps, e.g. v0.22.x -> v0.23.12 -> v0.25.9 -> v0.26.6 -> v0.29.3 -> v0.30.4 -> v0.35.0 -> etc.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Absolutely love using Pocketbase! Thank you for sharing it with us and congrats on the funding. Really excited to see what's next for the UI.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Mr. Gani, you inspire me!!!!! I really appreciate all your hard work. Wishing you the very best, and I hope your passion for PocketBase continues to grow it even further.

Thank you so much.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

Hello @ganigeorgiev any possible rough timeline for UI rewrite? Q1 end, Q2 ?

Is mobile responsiveness planned with this rewrite or it's gonna be done at later steps?

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

@modestaspruckus There are no ETAs.

I'm almost ready with majority of the UI rewrite (I'll make sure to optimize it for mobile devices) but I'm not planning publishing it soon.

One of the reason why I didn't bother with a UI plugin system from the beginning is that it is very "finicky" to maintain because even something small like changing later a CSS class or adding a wrapper div element can be a potential breaking change (not even talking about the hassle of documenting frontend changes).

I don't want to make promises or commit to deadlines/quarters. I don't think I'll have another opportunity like this again and I want to take my time experimenting and essentially address all tasks from the roadmap/todos to make sure that everything fit together in a way that I can feel comfortable maintaining the project in the long run.

So please be patient.

Beta

Was this translation helpful?

Give feedback.

There was an error while loading. Please reload this page.

So in the end I had to withdraw my FLOSS/fund application and decline the funding.

I've made a mistake for not researching it more carefully and not waiting for the disbursal before making big announcements and decisions, but it is what it is.

There will be a new announcement once I have more clarity and readiness to request community feedback.

I'll go ahead and lock this discussion to avoid further spamming the participants and repository watchers.

Beta

Was this translation helpful?

Give feedback.

Alex Chen