BubbleLab's README closes contributions and still links the contributing guide

The contributor door is shut and the guide is still linked

A dated callout near the bottom of the page says the project is no longer accepting code contributions or pull requests, and lists what it does still want: bug reports, feature requests, community discussion in a chat server, and documentation feedback. The same page then links the contributing guide twice, once from the community section and once from the local setup note about model keys, and the second of those links ends mid-sentence in the text. The repository has not been cleaned up to match the policy. There is a hooks directory, a commit conventions file, a code of conduct, a contributing guide and a separate assistant configuration, all of which are the standard furniture of a project that expects patches. The last commit on the default branch is dated 2026-04-30, so the code itself is not abandoned; what has stopped is the intake.

The open-core engine is not self-sufficient for its own assistant

The local story is two commands and one sentence:

pnpm install
pnpm run dev

After those two commands a studio is available on a local port. The note immediately under them qualifies that. Creating a flow with the assistant requires API keys, specifically a Google key, and a named model version is the default for generation. Code edits do not go through a model at all but use a fast find-and-replace. And a weaker model is described as not well tested, with degraded or inconsistent performance as the consequence. So the engine runs on your machine, the studio runs, and the feature the product is named after needs a paid third-party key and a model pinned by the vendor's own testing. That is a narrower open-core claim than the headline suggests, and the page is honest about it in a sentence most readers will skim.

Publishing bypasses git checks, and there are no releases

The repository has no published releases at all, yet its root script publishes five scoped packages to the public registry with public access and with git checks explicitly skipped. Those five are the shared schemas package, the core, the runtime, the project scaffolder that the Node package runner invokes, and a package for TypeScript scope management that the page never explains. Skipping the checks means a package can be published from a working tree with local changes in it. The build scripts are more careful: one builds three specific core packages, and the top-level build then builds everything except two of those three, so the two-phase ordering exists to stop the same package being built twice under a task runner that would otherwise run them in parallel.

The two command local start runs a shell script first

The documented quick start is a dependency install and a development script. What the development script does is not a single step. It runs an environment setup shell script, then builds the three core packages, then starts two applications through the task runner. So the first of the two commands a newcomer runs writes environment files before a single line of the studio is available, and the hot-reload variant repeats the same chain. The clean script deserves a read on the same grounds: it removes the dependency cache, the task runner cache, every package and application build output directory and every incremental build record, with no confirmation and no dry run option. For a monorepo that is a reasonable command to have. Having it as the first thing in the scripts block, above the build, is the surprise.

The performance figures come from a run six months before the last commit

The sample output block is dated 2025-10-07, which puts it six months before the last commit on the default branch. It records one execution of the Reddit template: ten posts from a single default subreddit, three bubbles executed in a named order, a total duration of 13.8 seconds, 1,524 tokens split into 835 input and 689 output, and a peak memory of 139.8 MB. Nothing on the page calls this a benchmark and there is no second run to compare it against, so the numbers are an illustration of what the output looks like rather than a claim about performance. The summary inside the same block carries a markdown heading, three truncated news lines and a placeholder standing in for the generated text, which is honest in a way that the timing figures are not.

The flagship code sample stops inside a string

The flow file is advertised as about fifty lines of TypeScript, and the excerpt shows the shape clearly. A class extends the flow base with a webhook trigger, a handle method destructures a subreddit and a limit from the payload with defaults, a scrape tool is constructed with those values and its action method is awaited, the result's posts array is read, and an agent bubble is constructed with a message built by interpolating the post count into a template string. The excerpt ends there, mid-word inside that message, before the string closes and before the call that the whole example is about. So the part a reader copies is the setup, and the part that would show how the result is used is in the template repository rather than the page.

One hosting target named, one Dockerfile, and it is for the API

Self-hosting is one of the two ways the page presents the product, and the other is the recommended one, the managed platform. The self-host story is thin in the details. The root carries a configuration file for a single hosting platform and a deployment directory beside it, plus exactly one Dockerfile, and its name says it is for the API rather than for the studio. There is no compose file. The local path is a development server on one port, which is fine for evaluating workflows and not much of an answer for running them for other people. So a team reading this page is told self-hosting is supported, and is given one host, one API container, and a development server for the rest.

Two assistant directories, two linters, and a workspace nobody mentions

The root is a mix of project and personal tooling. Two configuration directories sit for two different coding assistants, alongside a commit conventions file and an assistant instruction file. Formatting is handled by a prettier configuration and its ignore file while linting is handled by a separate ESLint flat configuration, so two tools decide what the code looks like. The task runner has its own configuration at the root. And one application in the workspace is named in a build script that compiles it, while the page's description of the system never mentions it: the studio and the API are the two the reader is told about, and a third is built by a script nobody is told runs. It is the sort of thing that surfaces later, when someone asks why a build takes as long as it does.

Editorial conclusion

The engine is genuinely open and genuinely runnable, and for building and executing workflows without the hosted platform that is a reasonable position to be in. Two things to weigh before committing to it. The assistant path is not self-contained, since flow creation wants a third-party model key on one pinned model with weaker models explicitly untested. And the project's own contribution policy is closed, which means the fixes you need will come from the vendor or from you, and the guide the page keeps linking will describe a process that is not currently open.

Frequently asked questions

Official sources

1. bubblelabai/BubbleLab on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README