How Boomla works


Boomla is a program that runs on top of your traditional OS like Windows, OS X, or Linux. On top of that, it provides an isolated, higher level environment that is ideal for websites. This environment has it’s own filesystem and users. It is transactional, so you don’t need to worry about concurrency issues. It also comes with a built-in webserver, so it is plug-and-play.

As said it is isolated, meaning from within Boomla, you can not touch your host OS. This is useful because this way whatever you build in Boomla will be portable across platforms. You can even carry a Boomla environment on a pendrive, and run it on varoius environments without converting your workspace. A workspace is just a bunch of data that belongs to a Boomla install.

Better filesystem, no DB

In most prior systems like Wordpress, there is no single place to store all your data. There is the filesystem and the database, with widely different properties.


  • transactional
  • strongly typed
  • enforce data integrity/relations
  • fast, concurrent access


  • access controlled
  • store large assets
  • hierarchycal (namespacing)
  • portable
  • accessible by non-techies
  • easily version controlled

Boomla has a new kind of filesystem with the purpose of providing a uniform data store for websites. It shares the best properties of both worlds. In Boomla, everything is a file.

Boomla files may have:

  • binary data,
  • file attributes, and
  • children, like files in a directory.

Each file can have all the above at the same time. Storing files with file attributes in a parent file is the equivalent of storing rows in a DB table. Instead of using SQL, you can query the Boomla filesystem similar to jQuery.

The Boomla filesystem is fast, transactional, file attributes are strongly typed, you can implement data relations via file links (similar to foreign keys in a database). We will also support enforcing data integrity via a feature similar to DB schemas.

Want to store a profile image for each user? Just place the uploaded image under the user object in the hierarchy, maybe named profile.jpg.


Boomla is filesystem based. Many developers draw the conclusion that correspondingly, Boomla must be slow. Let’s clarify something. Filesystem is a concept, where objects form a tree to hold data. Just like a car is a concept, where a box on wheels carries people and stuff.

These are concepts. There are also implementations. Some cars are slow, some are fast. Similarly, some filesystems are slow, but the Boomla filesystem is fast. Boomla uses techniques common to databases, not filesystems. The Boomla filesystem is indexed in memory, providing database like reponse times.

But there is more. Wordpress relies heavily on the DB. Even if Wordpress and the DB are on the same machine, they talk through a network connection with an extra communication overhead and latency. Lots of DB queries, lots of time.

The Boomla filesystem is part of Boomla. There is no network communication thus no overhead, making Boomla blazing fast.

Use your existing tools

As mentioned, the underlying OS is isolated from Boomla. This only means you can’t reach your underlying OS from within Boomla. Of course you can reach the Boomla filesystem from outside, which is useful for developing with your existing tools.

There are various ways to access the Boomla filesystem:

  • connect to it via SFTP,
  • on UNIX, mount the Boomla filesystem via FUSE - make the Boomla filesystem of your website appear in a directory of your host OS,
  • export the Boomla filesystem to your host filesystem.

Eventually we should get to a point where it is possible to develop Boomla purely from within.

Simple program flow

Boomla is built on a request-response model, there are no processes, there is no hidden state.

Because the entire Boomla OS is transactional, including the filesystem (and there is no DB), your code is the only one running. Well, this is not quite true, but it is guaranteed to appear so. The entire world is frozen and your code is executing synchronously.

Once a request hits Boomla, the file is looked up according to the URL. This file has an associated app, which is executed. Say this is a web page. If there are some contents, just render them. How does it happen? Boomla locates the apps associated with them, and executes them. That’s all there is. Apps run other apps, and return. Simple.

You can create any website this way. It’s just a different way of solving the same problem. Much like object oriented programming didn’t limit what you could do.

Composing apps

Any application platform is about composing. You install apps and so compose your system. That’s what you do on your PC, that’s what you do on Wordpress.

If programs would not run indefinitely, rather they would immediately return like in Boomla, we would end up with an interesting system. You could not only install apps which would then make up your system. You could compose apps to create new ones.

Let’s see an example. Say you have an image. An image app is trivial, it just returns the image data. You could create a new app that applies a grayscale filter to the image and then adds a watermark to it, without making these changes manually. You could achieve this by downloading a grayscale-filter app, an add-watermark app and then combine them in a single, new application. You would then update the file types of your images to use this new app. This is something even non-programmers could do. Even though, this actually is programming.

If you are a developer, this is similar to Unix pipes.

If this didn’t blow your mind, read this section again.

Isolated apps

On a traditional OS, programs are isolated from the system itself. They run in separate execution contexts, with clear boundaries and APIs between the parts.

In our website building frameworks, like Wordpress, there is no clear separation between system code and user extensions (or plugins). Thus, installing a new plugin can easily break your website.

A minimum requirement for a robust website builder is to clearly separate system and user space. Installing apps must happen in user space, and user apps must run isolated from system code. Adding a new feature must not break existing ones.

Boomla system code runs isolated from user-space apps.

Let me elaborate. Imagine you have a voting app on your website. Let’s assume it is buggy and crashes. Because each apps runs in an isolated environment, you will see an error message in the app’s place on your website and the rest of the webpage will work just fine. A single buggy app won’t bring your entire website on its knees. This also helps troubleshooting.

Lightweight execution contexts

As mentioned above, apps run in isolated execution environments. The cost of setting up these environments is one of the major reason we can’t use them for websites. Boomla is heavily optimized for that, the overhead itself allows for over 1M app executions per second. That won’t be your bottleneck.

Single concept of user

Most web developers, like those using Wordpress have to deal with 3 user concepts. One in the OS, one in the DB and one in the website builder.

Having a user concept in the website builder is required. The one in the DB is kind of simple, though not having it would be nice. But having a user concept in the OS is a painful legacy. It works very differently, it’s really hard to understand, it’s painful to work with. As a web developer, I really wish it wouldn’t exist.

In Boomla, there is a single user concept that transcends the entire system.

Zero external dependencies

Most website builders like Wordpress have external dependencies. They depend on the existence of Apache modules, PHP extensions, or other software preinstalled on your OS.

This means installing a website on a machine may take serious effort. The website won’t be easily portable, many developers are working directly on the server as they can’t replicate the environment locally. At least it takes lots of effort.

With Boomla, all the dependencies are part of your website’s filesystem. There are no external dependencies, which makes running your website in any environment a non-issue.

Version control

Boomla is a platform with a new kind of filesystem. While it is possible to use existing tools like Git for version controlling Boomla websites, they require one to step out of the platform, export the filesystem and do versioning there. This is not acceptable as one of the key promises of Boomla is to provide a platform one can use without knowing anything about its surrounding environment. Managing versions MUST be fully supported from within Boomla to live up to its promise.

Thus Boomla comes with built-in version control support. It features commiting (saving snapshots), deduplicated storage (storing an identical file on different versions doesn’t use extra storage), fast, cheap branching, easy deployments.

Live branches

You can create new branches of a websites with a click of a button. The new branch is created in an instant and is immediately accessible on a subdomain of the website. It also requires no additional storage. This is useful to experiment with changes to your website without your users noticing it. Once you are happy with the results, you can publish them with a few clicks.

Please note that all branches of your website are functional at the same time.


Enjoy undo/redo functionality for your entire website. This covers your files, installed applications, everything.

1-click deploys

From having version control and zero external dependencies follow that deployments in Boomla are extremely simple. You can work locally, then push your website into production with a single click. There is no sysadmin work and it is guaranteed to work.


PHP is the most popular programming language for websites on the server. As of this writing, leading with 82%. That doesn’t mean 82% of developers are coding in PHP. Most people who have installed Wordpress most likely have no idea about coding. The fact that most website builders are tied to a single language makes the Web fragmented.

What if you could program the same website in a variety of languages? Say, the menu could be written in PHP, the content in Markdown, the image resizing program in Golang and some usage statistics app in Haskell. That could unite developers in a single system, just like in the world of operating systems. The entire ecosystem could progress much faster.

That’s the goal of Boomla. Currently, you can only program it in JavaScript VMs, as we have to start somewhere, but be prepared for other languages. Eventually we will add a bytecode interpreter so that the community can roll custom VMs for various languages.

Less to learn

You don’t need to learn how to install and configure a webserver. Boomla comes with a built-in webserver that is automatically configured for you.

You don’t need to learn how databases work. You don’t need to learn how to create consistent backups.

Most websites are hosted on Linux. With Boomla, you don’t need to learn Linux. Linux users and permissions are particularly complex.

Starting and managing processes is hard. In Boomla, there are no processes as it is built on a request-response model.

You don’t need to learn the tricks of working in a concurrent environment. Of course it is easy if nothing goes wrong, but what if an other process changed something you relied on? This is so hard that even most filesystems used in production are full of unhandled edge cases, you can find comments like TODO: handle this.

Of course you do need to learn Boomla itself, but the multitude of legacy solutions (eg. FS + DB) are replaced with uniform ones (FS). Thus there are materially less parts and the hard problems are replaced with simple ones.

Write less

Boomla apps are generally shorter because of the filesystem and that some problems are solved for you centrally by the platform.

As there is no DB, you don’t need to connect to the DB and handle DB query issues.

Often you don’t need to implement entire classes. Say, you want to write a conversation app using a database. You would implement a conversation class with methods create, getById, createComment, comments, store, remove. You would also implement a comment class with methods getById, conversation, store, remove. Implementing these is lots of boilerplate code which you write before you write the acutal app.

In Boomla, you could completely avoid writing these classes, you could simply rely on using the powerful structure of the filesystem.

On the Boomla filesystem, a conversation would typically be a file, with its file-type set. It would contain other files, which would be the comments. Thus, implementing conversation.createComment() is not necessary, you could use the filesystem API for creating a new file with Same goes for the other methods. Removing a conversation is conversation.remove(), which also removes the entire subtree (the comments). In the database world, you would first have to remove the comments by conversation ID, then remove the conversation itself.

We implemented some apps first on a LAMP stack then on Boomla. The Boomla equivalent was consistently about 17x shorter.

Simple to install

Boomla comes with no external dependencies. No Apache, no MySQL, no PHP to install and configure. Just download and run.

Simple to start hacking

No system can be truly simple if taking the firsts steps requires lots of effort.

In Boomla, to create a JavaScript program printing hello world, you just need to create a file, set its file type to execute JS code and set its contents to os.print("hello world"). Done. It will show up on the page that contains the file.

There is no configuration, no boiler-plate code, nothing. It’s like writing a simple hello world program in an empty file, directly on your OS, without any framework. After all, Boomla is an OS, not a framework.