Before Budibase, my cofounder and I worked together, and we were constantly tasked with creating CRUD apps for internal operations - the development process was repetitive, frustrating, and time-consuming. At the time, I looked at low-code options, but there was no standout open-source option.
So, my cofounders and I have spent the last 3 years creating Budibase, an open-source low code platform, to make it faster, easier, and more enjoyable to build CRUD apps [forms, admin panels, approval apps, portals].
We believe low-code platforms should seamlessly integrate with a company's tools and operations. With Budibase, you can create apps using:
MySQL, PostgreSQL, Rest API, and more.
Or you can start from scratch with Budibase's built-in database (built on Apache CouchDB).
Right now, Budibase supports Open ID Connect and Google Auth. It also supports automations using Slack, email, Zapier, Integromat, Webhooks, JavaScipt, and you can run scripts, queries, CRON jobs.
To design your apps, you basically add pre-built components [forms, tables, charts, buttons] to screens, then bind data to those components using Handlebars or JavaScript. Budibase apps work across desktop, tablet, and mobile.
As you create more apps and automate more processes, the reliance on Budibase grows. So, we think it's important that you can 100% own your data and self-host Budibase on your own infrastructure (Docker, Digital Ocean, Kubernetes). Deploy Budibase with our pre-packaged Redis, MinIO, and CouchDB or connect to your own existing Amazon S3 compliant buckets, Redis clusters or CouchDB instances.
Happy to answer any questions. We have a lot more to build and love to hear use cases and feedback.
Installing the budibase server from npm pulls in over a thousand transitive dependencies. The npm install command reports that there are 39 known vulnerabilities in budibase's dependencies, including 9 that are classed "high" and 3 that are "critical" severity.
The dependency graph includes a lot of crap, like packages containing trivial single-line functions like "is-object" and "is-stream". That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1].
I'm interested in hearing from the creators what steps they take to audit their transitive dependencies in order to prevent this application from being compromised. Given that a tool like this would typically be given privileged access to internal data sources, it seems like a tempting target. I don't think I'd be comfortable using this in production.
Thanks for the comment. We have just undergone a full security audit as of 2 weeks ago - any infrastructure or code vulnerabilities are currently being worked on.
Many JavaScript projects contain huge dependency trees - it is unfortunately the nature of a 3rd party module-heavy ecosystem, and can be hard to tame the sheer size of the tree. We will update or pin dependencies as needed, to solve the security issues being reported by NPM.
I should also mention that since budibase is self-hostable, it can be run inside all of your existing infrastructure and network - providing additional layers of security that you can control.
Appreciate the feedback, and the information regarding transitive dependencies - interesting article.
You're not wrong, but also, npm audit is pretty much a joke, and those "high" vulnerabilities aren't as bad as the terminal would want you to think. Should absolutely be fixed, but just relying on npm audit is a bit simplistic.
Your critique about packages for is-object is valid, though.
>"The dependency graph includes a lot of crap, like packages containing trivial single-line functions like "is-object" and "is-stream".
I've never understood introducing this kind of dependencies. Depending on the legal conditions (usually favorable) one can simply extract the code they need from those packages and put it into some consolidated lib on their own.
As it becomes more difficult to sustain tech choices related to Javascript, I wonder if the web industry will start to slowly divest from it and embrace decent technologies using Wasm, or if we're past the point of no hope to free ourselves from JS...
I've been looking for a no-code solution to quickly build webapps on top of APIs exposed for mobile apps. I've been documenting OpenAPI specs[0], and evaluated most Nocode solutions in the market, trying out the "Rest API" integration in all of them.
Did the same for Budibase, and here's some feedback (on just the REST API integration):
2. Provide html input placeholders in all fields. Understanding whether "Url" field refers to the base URL, or a complete endpoint URL (different platforms treat this differently) is confusing. Even things like whether or not it needs a trailing slash. Having a placeholder with a standard API (such as OpenAPI Pets example) makes it easier.
3. The Jinja template format is great (I don't think any other platform came close to what this simple solution does) - but it isn't documented well enough. The API endpoint creation form should guide me to it as a possibility - without me having to look for it.
4. Really liked the auto-schema detection.
5. The forms really need to be more explanatory. ("Parameters" could refer to HTTP body parameters, or REST API parameters, but it's unclear)
6. Rough edges such as [1] should either be fixed, or automatically be disallowed.
As an aside, I'm curious why the entire nocode industry docs are on GitBooks.
We are actually currently planning work to greatly improve the experience of the REST API integration (including better docs) - due to it being such a fundamental part of building any software.
1) Good catch, we will fix that right away.
2) Great suggestion, this will definitely help guide the user.
3) Very valid - there will be a more wizard based experience for the REST connector soon. It's quite manual at the moment. Appreciate that you liked the handlebars templating experience!
4) This is a big feature for budibase - we try and auto generate as much as we can, to make the dev experience faster.
5) More docs and guidance around this is on the way with our "blocks" feature, which should make building forms a much more pleasant experience.
6) as above.
Gitbooks is a pretty nice platform - it takes a lot of the effort out of creating/designing docs and they recently updated their editor, so we are very happy with it!
I don't have much to say other than your landing page actually told me exactly what I could do with Budibase, which seems to not happen as often as I would expect. I always check out new stuff like this, and I'm often left wondering how this new thing works. Nice work explaining what you do! It's not something I'd likely need, but at least I know what it does.
Thanks, really glad to hear that! If you do ever end up trying the platform, don't hesistate to reach out and ask questions on our github discussions forum.
hey. why don't you build some templates for accountants because this looks a nice thing for people like us but we aren't devs and coding financial statements from scratch, the db and all looks like a huge deal.
i can totally see using this but "handholding" would be great.
That's cool. Have known the founder and liked their product and seemed relevant hence suggested.
Do check out Appsmith (https://github.com/appsmithorg/appsmith), I work here and we're an open source low code framework for building internal applications. We haven't really thought about the accounting use case, but now that you mention it, it could be super interesting (we've ofcourse had a lot of users building for HR, IT, Sales & Marketing use cases, other than the support).
I really appreciate how forward your product is with pushing the open source version. After clicking around for a bit in Cloud, it made is so easy to commit to a local install.
Budibase is definitely a product I could see preferring to spend on Enterprise, unless there was a very compelling my team could accomplish "more" with self-hosting. I just ask that if you end up with some sort of per-user/seat fee, that you follow Slack's lead and charge only for activity. This will win my heart over.
Also, custom domain support. Execs love their vanity URLs.
I don't see any demo here. Just one demo to show all strengths of the platform is still the fastest way to persuade user (like me), else i have many doubts and questions like, what it can do ? Can it do this ? How to do this things,...
I would like to see a hosted tier between Enterprise and Free.
maybe something like $10/dev plus upcharges for storage and data transfer. but unlimited apps(or at least a generous amount of apps). and an issue escalation charge.
I notice you've used two different programming languages to express application logic. A the high-level, you have automations, which are simple but look very limited in terms of capabilities (i haven't studied this part in great detail, but does its support things like looping, arbitrary conditional expressions, and an abstraction mechanism like user-defined functions?). At the low level, you have JavaScript to do fine-grained data manipulation, which is often necessary to take care of details like computing summaries of data or transforming between different formats.
I've seen this approach used in a lot of different workflow systems over the years, and it's always struck be as awkward. Have you considered designing the automation language in such a way that it is sufficiently expressive to cover the full range of needs for apps, from the high-level aspects to the low-level details?
The approach I prefer to use is to pick a suitably generic language (generally based on a formal process calculus and extended with useful primitives). I'm on my second round of doing this now (first as an academic research project, now in industry) and in both cases it's been based on lambda calculus (and in the industry project, based on Scheme). The language constructs and model of computation are identical whether you're implementing high-level aspects of the workflow logic (a sequence of steps, with optional conditional branches, looping etc) and low-level aspects (iterating through a list of numbers to compute the sum). One language + interpreter takes care of both. I discuss this approach in Chapters 2 and 3 of https://www.pmkelly.net/publications/thesis.pdf.
I’ve read your abstract and it looks very interesting! I’ll be diving into the rest as I find time over the next few weeks thanks for sharing! And well done on this piece of work!
It was interesting to me that you mentioned “functional programming as a model for data-oriented workflow languages”. I find it interesting because we are building Lowdefy [0] with which you can express feature rich apps in yaml / json, and have been considering how to implement DAG type stuff in future versions.
We’ve taken a lot of inspiration from Mongodb aggression query language and as a result built a json / yaml parser which evaluates functions (operators) to implement logic throughout the app. This proved to be extremely flexible, easy to use for data manipulation, and surprisingly performant as we can actually evaluate the expressions during the render loop.
Automations are simple by design - the general automation steps are kept simple so they are easy to configure and create. We do however have a JS and a bash automation block. These blocks let you perform looping, iteration and logic using either JavaScript or bash.
The reason we use JavaScript is simple. Most software engineers can write or at least express simple constructs in JavaScript. Being a C family language, this makes it easy to pick up for engineers who have been exposed to other languages like Java, for example.
The problems you are describing are actually something that we have felt before, when budibase did not have JS support, we had users reporting that the templating/handlebars syntax was not good for logic, and was new to them. It was esoteric and required in depth knowledge for advanced use cases.
Using an off-the-shelf high level or more specific expressive language has some serious drawbacks, especially if you create it yourself. The first is education - writing extensive docs around how to write and use that language. The next is maintenance - maintaining your own custom PEG grammar or programming language is a huge project in itself, not even including the research required to execute it well.
By using JavaScript, we can leverage the already existing plumbing for executing JavaScript, and provide something that has much for familiarity to the general user.
I'm currently evaluating this for use at our healthcare company, and I can tell you that 100% of the reason why I'm even willing to consider a low code platform like this is because of the excellent job you've done with open source, and the fact that it fits in seamlessly to our existing nodejs and javascript environment and skill set.
Had you guys made the decision to create your own grammar/DSL, it's very unlikely that I would be seriously considering using it.
I have played around with this product a few times over the last few months! It's getting better with every release. I used it for an internal work tool last week and was able to be up and running in less than an hour, where normally I'd have spent a day at it. Using the blocks lets me forget about the design as well.
TLDR; AppSmith and Budibase are quite different platforms, but with significant overlap.
Budibase is meant to be used by IT Professionals (sysadmins, dbas, IT managers, PMs, developers). AppSmith is more targeted at developers. Because of this, Budibase has much less of a reliance on code - we like to say “code optional”.
Also, you will see us talk more about “Business apps”, rather than “Internal Tools”. A Budibase app is a real, single-page application - which you would happily give out to external users and folks in other departments who do not need to know your team’s internal processes. The apps are also responsive by default.
Another differentiator is that Budibase comes packaged with a database (runs on CouchDB). This makes creating new applications easy - without having to spin up another DB. We also offer 1st class support for SQL Databases - Budibase will automatically fetch your tables and automate the basic INSERT, UPDATE, SELECT and DELETE statements (like an ORM).
If you want to place us in the overall low-code landscape, we are more like an open-source Powerapps/Mendix/OutSystems. I sometimes say (half-jokingly) that Budibase is what would happen if Retool and Stacker had an open-source baby.
hey there, here is Rob, co-founder at Chartmat. Congrats on your Launch. this looks amazing. Also super interesting thread on HN.
At Chartmat we also provide internal apps, forms & dashboards (we are at an early stage though). however, we are targeting non-technical users (no-code niche), since we found it hard with our previous low-code iteration to get enough users.
I wish you guys all the best on your way & I'm always happy to exchange experiences. Keep the good work up!
Appsmith founder here. Congratulations on launching Budibase! I think it's a beautiful product.
Like MJshanks mentioned, there's some overlap in the usecases but there are significant differences in the platform direction. Budibase is more no-code, while Appsmith is geared towards developers aiming to build complex applications.
Appsmith is a more popular and mature tool with high quality documentation, video tutorials and stellar community support. The GitHub stars, issue list, and size of Discord community reflect this. [0]
1. According to users who've tried both, Appsmith's UX is simpler and enables building information dense UI. Appsmith has drag and drop to build absolute UI vs. relative positioning in Budibase. This does make Budibase apps more mobile responsive than Appsmith ones. Links to comments by other HN users [1] [2]
2. Appsmith is a more powerful platform with a high ceiling and low floor for entry. You can build simple apps quickly by auto-generating them. In Appsmith, you can write full-fledged JavaScript anywhere on the platform. This ensures all your business logic is always expressed correctly. You can map over data, merge data from different data sources, trigger conditional workflows, and conditionally control widget properties all with a few snippets of code.
Few more feature differences:
1. Appsmith has more UI components and support for 100+ charts
2. Built in git sync for version control
3. Real-time commenting and real-time editing(WIP) to enable collaboration between users
4. Appsmith has organizations/workspaces to help freelancers manage multiple projects
5. Error logger and linter to debug issues
Honestly at a more fundamental level, it's just great to see all the different products that have come out over the years that are trying to tackle the same problem space. When we started out initially, we didn't find any open-source alternatives (Budibase wasn't open source then), and so we embarked on building it. And now it's great to see so many different products, which gives users more choice and power over finding the platform that fits their needs best.
We haven’t yet worked out out our pricing model for Budibase Cloud. However, it will most likely be user-based / per seat - similar to platforms like Retool & Airtable.
Such pricing models would prevent any kind of resale for most products. Please at least consider a pricing model which allows for something like 1 USD per MAU, for instance if data isn't shared between users (could a SaaS be build on budibase which cost 10 USD per month to the end-user).
I hear you! Budibase is not meant for building a SaaS product. However, it's good for "Customer Portals" - whereby you are giving access to external users. This is a problem for per-seat pricing, but there are ways to solve it.
We've thought about pricing per MAU. The difficulty is that we would always be charging for last month's usage, rather than more predictable upfront charging. Also - coming up with an exact definition of "active" is not trivial!
I haven't played with the api connector, but where do you store the api keys? is there a way to throttle the calls and hide them behind authentication so a user doesn't just blast my api if it's a paid service?
Looks great! I've used budibase before and it's looking really well these days, loving the UX improvements. Are there any plans for out of the box metrics or monitoring? e.g. with open source tools like prometheus
Thanks - we have been working hard on making UX a priority for budibase and glad to see that it's paid off!
We plan on introducing a self-hostable metrics stack built on exactly the technologies you mentioned in the next few months. Grafana, Loki, Prometheus and more.
This should give users total insight into what's going on in their budibase installations and allow them control over their budibase infrastructure.
My use case may or may not have been part of the intended initial focus of Budibase, which was to create an MVP to test and refine an idea. I am not a dev, but I was able to find my around it for the most part. To me, it was like an updated, easier to use MS Access alternative. When I was stuck, I joined their Discord chat room. The founders were prompt and informative in response to my questions. Congratulations on the launch. To success. Ace.
I was really excited about Budibase when I first discovered it but then you did away with management for external users and made them shared across the whole Budibase installation. A very enterprisey move.
I really wish someone would come up with a tool like this that isn't targeted at the enterprise, there is definitely a market for it. I could see using this for a host of use cases if user sign-ups were supported.
Got to say a big thanks to the team for what they've built so far, always enjoy using Budibase and find myself recommending plenty of other people to give it a try!
Btw I love seeing the monthly updates Budibase showcase on your YouTube channel, keep them coming! Makes me excited seeing more and more features added each and every month on top of everything that is already there.
I don't understand why it's only for internal applications.
If the form looks good and works, I would put it as a solution for my customers.
Maybe I would not create the whole application with Budibase, but for some screens for entering data + showing tables, yes.
What reasons do you think this is not feasible?
And as a business idea, I think that the first "no code"/"low code" that removes the "only for internal apps" will get the most developers interested. (like me)
The point that foxbee was trying stress is that Budibase is not for building SaaS products.
There is absolutely no reason why you could not give login's out to your customer - i.e. a customer portal.
It's just difficult to draw this distinction with simple terms, so sometimes we say "Internal" to try and separate from "SaaS Product". Naming is hard - we've been using the term "Business App" more often now.
I see a lot of no/low code tools as being “for internal apps”, (I think Vercel is one such) but I always wonder why exactly they are only meant for internal apps and not for building a SaaS product. Care to enlighten me?
Our problem and reason for creating BB was because we were continually creating similar internal CRUD apps, time and time again. Building a SaaS platform was not our problem.
i gotta ask about the tradeoffs of being open source. It's great for trust and marketing, but if people can self-host Budibase they're always weighing DIY vs paying you. I also work in an open source company and I know product development is often slowed because you have to consider the open ended needs of the open source users vs the constrained assumptions of your cloud.
Any insights or rules of thumb you've developed to think about running an open source business?
Thanks! Open-source has been fantastic for us. We've only recently launched our cloud platform, yet we've had a good sized community using Budibase and feeding back issues, feature requests etc. for ages. Building an open-source product has been so rewarding that way.
Of course, you're exactly right - we now have another ball to juggle; keeping our cloud up and running!
It took us nearly 3 years to open our cloud up, but I'm so glad that we left it this long. Only now do we have the engineering resource to handle open-source/self-host and cloud whilst still keeping the pace of development up.
So, for tips - work on product, product, product. Build your community and give them a great open-source offering. Your community will give back in return - even pure product feedback is gold. Then launch cloud when your direction is solid and you're confident in your product.
Our app metadata is stored as JSON documents in CouchDB, but entire apps can be exported to .txt files that can be imported into budibase also. Our templates work through this method.
We do not currently support git based versioning, although it's certainly something we could support in future, given the fact an entire app can be represented in a .txt file.
Really glad to see you guys launching out of beta! I remember trying Budibase a while ago, one thing I notice you didn't mention was an Oracle database integration, is this something that might happen any time soon?
We are currently in the process of shipping an oracle integration and it will be available in our release next week!
Our oracle integration will also include automatic schema fetching and query generation, so we can completely automate CRUD operations against your existing oracle database.
I attempted to use this a few months ago to prototype a unified ticketing solution (just an experiment to see if it would be worth adopting for small internal apps) using pre-existing mongo data. Seems super early to use this for anything serious in my view.
TL;DR - It ended up being orders of magnitude faster for me to just build it from scratch.
One of the biggest general UX issues I encountered was how data sources & queries are defined in the UI, and then how they're bound in the WSYWIG editor. It wasn't immediately obvious and the docs are pretty lean. In most cases, I'd just prefer a config file vs doing everything via the UI.
I like the idea and how flexible it aims to be generally, but its in very early stages right now.
(Small aside: There was also a showstopper mongo bug as well that would have prevented me from moving forward with the tool even if I liked it. It was a simple async issue, 11 line diff to fix, but took months to merge.)
It is open source, self hosted and you write your apps in config (yaml / json). So your are not trapped in a UI, you are free to copy paste find and replace and you can version control as you like.
Also, we use it extensively with mongo.
Thanks! Just looked through the docs, looks very well thought out.
I mentioned elsewhere in this thread that no/low-code tooling rarely ever works out in my org (mostly because its hard to make a generic framework to encompass what we like to do with internal tooling) — but will absolutely check this out and provide some feedback if I think I have something useful to contribute.
Hi, thanks for the feedback, sorry to hear you had some problems.
The Mongo connector in general could probably do with some love - there's a few features in mongo such as projections that budibase does not support. We'd love to know more about what you were trying to build and how we could help you achieve it.
We move quickly, however, and the platform has come a long way in even a few months. We hope you try the platform again soon and continue to provide feedback as to where it could be improved.
Docs are a big focus for us over the coming months and they will see significant improvement in short order.
I'd be happy to help out on the mongo side if you'd like. Maybe some github issues with a related label to help triage those issues would be helpful for folks to lend a hand.
I'll concede that no/low-code solutions have never historically worked out at my organization (context: I am cofounder and director of engineering at a wireless ISP). Theres always a set of tradeoffs that make it really hard to deliver value when you're dealing with business domain constraints that are hard to generalize.
That said, I am always willing to give things a fair shot and have a long list of small use cases that I use for prototyping when I go down that rabbit hole.
Looks cool. Impressive
video and I like the humour. Nice to see this come out of the UK too. Could this be used to build a SaaS or is it just for internal business apps?
Strange - Safari supports Webp in v14. Also, I've tested the website on two computers, both Safari v14 and they appear. Apologies for this and thanks for letting us know. I'll keep digging.
congrats! I work in a similar space, and this looks promising. Suggestion for your marketing team - the promo demo is great, but make it HD. The demo recording is pixelated on 4K res. You can do better :) Good luck!
Budibase is a low code platform for creating CRUD apps, and an open-source alternative to PowerApps, Mendix, and OutSystems.
The Github repo is : https://github.com/Budibase/budibase
And our website is: https://budibase.com
Before Budibase, my cofounder and I worked together, and we were constantly tasked with creating CRUD apps for internal operations - the development process was repetitive, frustrating, and time-consuming. At the time, I looked at low-code options, but there was no standout open-source option.
So, my cofounders and I have spent the last 3 years creating Budibase, an open-source low code platform, to make it faster, easier, and more enjoyable to build CRUD apps [forms, admin panels, approval apps, portals].
We believe low-code platforms should seamlessly integrate with a company's tools and operations. With Budibase, you can create apps using: MySQL, PostgreSQL, Rest API, and more. Or you can start from scratch with Budibase's built-in database (built on Apache CouchDB). Right now, Budibase supports Open ID Connect and Google Auth. It also supports automations using Slack, email, Zapier, Integromat, Webhooks, JavaScipt, and you can run scripts, queries, CRON jobs.
To design your apps, you basically add pre-built components [forms, tables, charts, buttons] to screens, then bind data to those components using Handlebars or JavaScript. Budibase apps work across desktop, tablet, and mobile.
As you create more apps and automate more processes, the reliance on Budibase grows. So, we think it's important that you can 100% own your data and self-host Budibase on your own infrastructure (Docker, Digital Ocean, Kubernetes). Deploy Budibase with our pre-packaged Redis, MinIO, and CouchDB or connect to your own existing Amazon S3 compliant buckets, Redis clusters or CouchDB instances.
Happy to answer any questions. We have a lot more to build and love to hear use cases and feedback.
If you are interested, try it out:
https://github.com/Budibase/budibase
https://budibase.com