# Budibase: Building AI Agents and Internal Apps on Your Own Infrastructure

> Budibase is an open-source operations platform that combines AI agents, workflow automations, and application building in one self-hosted system. The core code is GPL v3; paid features ship under the Business Source License.

**Budibase/budibase** — AI agents, automations and apps that run your operations. Model agnostic.

- Repository: https://github.com/Budibase/budibase
- Website: https://budibase.com
- Stars: 28,321 · Forks: 2,226
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/budibase-budibase

## What Budibase Is Built to Replace

Engineering teams inside growing organizations typically face the same problem: employee requests arrive through email, approvals live in spreadsheets, and process automations are cobbled together from webhook scripts and third-party integrations. The result is a collection of disconnected tools that require continuous engineering time to maintain.

Budibase targets that problem. The README describes it as a platform for handling requests, automating workflows, managing processes, and connecting business systems without stitching together multiple tools. The intended audience is engineers who build internal operational tooling and the operations teams who run it.

The platform produces three types of outputs: AI agents that receive employee requests and act on them automatically, automations that run cross-system workflows, and apps that provide the interface where employees submit and track work. This focus on operational coordination is distinct from building a customer-facing product. Budibase is not a general application framework; it is a system for internal work management.

The README states that Budibase agents understand requests and handle the work automatically, creating records, routing approvals, updating apps, and notifying teams. Whether an agent in practice handles your specific request type depends on the underlying model configuration and the tools you connect to it, none of which the README describes in technical detail.

## Agents, Automations, and Apps: How the Three Layers Fit Together

Budibase organizes its output into three categories, each handling a different layer of the operations problem.

Agents sit at the intake layer. According to the README, employees ask questions, request approvals, and report issues. Budibase agents receive these inputs and run workflows across the business in response. The README says they are model agnostic, meaning the agent layer is not tied to a specific LLM provider.

Automations form the middle layer. They connect databases, AI models, and business apps so that an agent action or a form submission can trigger work in another system.

Apps are the interface layer, where employees actually interact with the system. The packages/builder package contains the Svelte-based builder that teams use to design forms, tables, and dashboards. The packages/client package is a browser module that reads a JSON definition produced by the builder and renders the live application from it. This separation between a definition and a rendering layer means apps are described as data, not as hand-written code.

The packages/server package is a Koa application responsible for serving the JavaScript for both the builder and the rendered apps, and for providing the API that connects to the database and file system. The monorepo is managed by lerna. The root package.json lists lerna at version 10 and uses Yarn as the package manager.

## Self-Hosting Options and Local Development Setup

Budibase supports five self-hosting deployment methods: Docker (including a single ARM-compatible image), Docker Compose, Kubernetes, Digital Ocean, and Portainer. The README directs readers to docs.budibase.com/docs/hosting-methods for the installation steps for each option.

For engineers who want to run Budibase locally to evaluate the codebase or contribute to it, the root package.json defines a setup script that handles the full initialization sequence:

```bash
yarn setup
```

This runs `git config submodule.recurse true && git submodule update && node ./hosting/scripts/setup.js && yarn && yarn build && yarn dev`, which initializes submodules, runs the project setup script at hosting/scripts/setup.js, installs all dependencies, builds the full package graph using lerna, and starts the development server.

The build step sets NODE_OPTIONS to --max-old-space-size=1500 and disables the V8 compile cache. If you encounter out-of-memory errors during a local build, the max-old-space-size value is the setting to increase. The project requires Node 22 (specified in .nvmrc) and Yarn.

For teams that prefer not to manage infrastructure, the cloud option is available at account.budibase.app/register. The README presents both the self-hosted and cloud paths as first-class options.

The public REST API is documented at docs.budibase.com/docs/public-api, with an interactive reference at docs.budibase.com/reference/appcreate. The API enables using Budibase as a backend for other applications and building integrations between Budibase and external systems.

## The Monorepo Layout and Package Boundaries

Budibase is a TypeScript monorepo. Understanding the package boundaries matters for contributors and for teams that need to modify or extend specific parts of the system.

The packages/builder package is the Svelte-based frontend where users design apps. The packages/client package runs in the browser, reads the JSON output from the builder, and creates the running app. The packages/server package is the Koa server that connects everything: it serves the builder and client JavaScript, and provides the API layer for database and file system access.

Beyond these three core packages, the monorepo includes packages for the CLI (@budibase/cli), the backend core (@budibase/backend-core), the SDK (@budibase/sdk), the frontend core (@budibase/frontend-core), and the pro package (@budibase/pro). The build script in package.json shows which packages participate in the npm publishing scope.

The repository also includes a charts/ directory (for Kubernetes Helm charts, indicated by the artifacthub-repo.yml file at the root), a hosting/ directory containing deployment scripts, and an i18n/ directory for internationalization. The global setup script at hosting/scripts/setup.js is the entry point for local environment initialization.

The CONTRIBUTING.md at docs/CONTRIBUTING.md is the reference for setting up a development environment, and it includes a troubleshooting section for clearing the environment between builder updates, which suggests that data or schema migrations between versions require explicit steps.

## Where Budibase Has Real Limits

The README describes capabilities but is silent on several concerns that matter in production.

Rollback behavior for failed automations is not documented. When an agent routes a request and one downstream action fails mid-sequence, the README does not say whether earlier steps are reversed or left in place. Teams running financial approvals or data mutations need to test this behavior before deploying.

The licensing structure requires legal review. The GPL v3 applies to the core, the MPL 2.0 applies to the client and component libraries, and the Business Source License applies to packages/pro. The README states that apps you build with the client and component libraries can be licensed however you like, which addresses one common concern. But the BSL on paid features adds a separate review step for commercial deployments. The specific BSL terms are in packages/pro/license.md, not in the main README.

The build toolchain has specific version requirements. The monorepo requires Node 22 and Yarn. The devDependencies include pinned versions of TypeScript (6.0.3) and Svelte (5.40.2). Organizations with existing Node version constraints may need to manage these with a version manager before the setup script can run.

The README does not describe a documented migration path between major Budibase versions. The CONTRIBUTING.md troubleshooting section covers clearing the development environment, which implies that significant changes to the schema or data layer do occur between releases.

## Building From Scratch vs Using Budibase

The direct alternative to Budibase is building internal tooling using a standard web framework. A team using a framework like Next.js or Express writes its own data layer, form handling, approval routing, notification system, and agent integration. This gives complete control over every component and imposes no additional licensing constraints.

The trade-off is development time. The README positions Budibase as saving engineers hundreds of hours building agents, apps, and automations. A custom stack models your specific workflow exactly, while Budibase is a general-purpose system that may require configuration to handle unusual process patterns.

For AI agent workflows specifically, a custom stack means integrating an LLM provider API, building prompt management, and building the state machine for multi-step agent tasks. Budibase provides this infrastructure through the builder interface, with agents connected to databases, AI models, and business apps.

The line where a custom stack wins: when the workflow is genuinely unusual, when your data model does not fit the form-and-table metaphor that Budibase apps are built around, when you need to distribute the tool externally (which interacts with the GPL v3 terms), or when the BSL restrictions on paid features conflict with your commercial plans.

## License Tiers, Maintenance, and Upgrade Cost

The README states the licensing structure explicitly: the platform core is GPL v3, the client and component libraries are MPL 2.0, and paid features are under the Business Source License.

Under GPL v3, any modifications to the core packages that you distribute externally must be shared under the same license. Internal self-hosting without external distribution does not trigger this requirement.

The MPL 2.0 on the client and component libraries is more permissive. The README states that apps you build can be licensed however you like. This addresses one of the main concerns teams have when building internal tools on an open-source platform.

The Business Source License on packages/pro restricts commercial use without a paid agreement during a specified period. The BSL typically converts to a permissive open-source license after a set time (the exact terms are in packages/pro/license.md).

On maintenance: the last push to the repository was on 2026-09-25, three days before this article. Release v3.46.0 was published on 2026-09-21, and v3.47.0-cloud.1 on the same day. The project maintains a cloud release track (v3.x.x-cloud.x) in parallel with the standard release track, which suggests separate deployment pipelines for hosted and self-hosted users. The pace of releases indicates an active development cycle, but the upgrade cost depends on how much you customize the packages/pro layer or any core packages, since those changes will need to be reapplied on each update.

## Conclusion

Budibase suits teams that need to build request-handling workflows, approval routing, and internal apps without standing up custom backends. The self-hosting options (Docker, Kubernetes, Digital Ocean, Portainer) are directly supported by the project. Organizations building customer-facing products, or those that need a fine-grained custom workflow engine, will find the GPL v3 core and the Business Source License paid tier add compliance review. Before adopting, read packages/pro/license.md in the repository to confirm which features in your target use case fall under the BSL, since the README does not itemize the boundary.

## FAQ

### What is Budibase used for?

Budibase is used for building internal operations tooling: AI agents that handle employee requests automatically, workflow automations that connect business systems, and internal apps for data entry, approvals, and process management. The README describes it as a platform for handling requests, automating workflows, managing processes, and connecting business systems in one place.

### Is Budibase free?

The Budibase core is open-source and free under GPL v3, and the client and component libraries are under MPL 2.0. Paid features, housed in packages/pro, are under the Business Source License and require a paid agreement for commercial use during the BSL period. A free cloud registration is available at account.budibase.app/register.

### How do I install Budibase on Docker?

The README lists Docker as one of five self-hosting methods, including a single ARM-compatible image and a Docker Compose option. Installation steps are documented at docs.budibase.com/docs/docker and docs.budibase.com/docs/docker-compose.

## Sources

- [Budibase/budibase on GitHub](https://github.com/Budibase/budibase)
- [Issues](https://github.com/Budibase/budibase/issues)
- [Project website](https://budibase.com)
- [README](https://github.com/Budibase/budibase/blob/master/README.md)
- [Releases](https://github.com/Budibase/budibase/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/budibase-budibase