Deep diving

We want to eliminate the hassle when it comes to server management. So we used known technical patterns to create a product, which is also usable for non-programmers. And this is, how we did that.

The event log

Under the hood, rootli writes all changes related to your projects, including servers, sites and databases, to an event store. This event log is append-only, as you might know it from accounting. As every single change is stored, the state of that project can be queried for every moment that this project existed.

This is not only a nice auditing feature, it also opens up new possibilities: Each server's status can be cloned to a new server based on a given date.

Applying infrastructure and configuration

As you now know, the state of your project is stored in a series of events, which make up the current state of your project. This state can be expressed as structured data.

When it is required to apply changes to your infrastructure or your servers (e.g., if you added a new server or deleted a database), an isolated deployment runner makes sure that your infrastructure (servers, firewalls, networking) matches the defined state.

Additionally, each server's state is applied. This basically means that this process tries its best to not only apply changes, but also to revert changes that are not defined in the beforementioned structured server-state.

Source of truth

This also means that rootli is the only source of truth. All structural changes like changing the root-user's password, adding custom firewall-configuration etc. can be reverted by rootli. By design, we prefix our content with rootli_, which implies that you should prevent to add anything with that reserved prefix.