It's very early - it doesn't do much yet (but what it does do is compelling!). There isn't a ton of documentation, but we have put a lot of real user research into things.

1. Authentication works through Auth0. We're building towards multiple deployment models, where your account works across all of them. That said, it's all open source, so if Auth0 doesn't work for someone, we're happy to make it pluggable.

2. You can model anything you like. Under the hood it's a hypergraph of Typescript functions - so you would model Grafana, and then make calls to its API when actions are needed.

3. It's built in to the model via change-sets. As you do change the model, we show you whats changed, and what actions we would take. The design is heading toward letting you have comprehensive reviews based on which portions of the entire model are impacted. Roll-backs aren't really a thing in infrastructure land, but you can see old versions of the model and decide you want that to be the current one.

4. We model the upstream 1:1 - so that configuration uses the default VPC in the AWS account (which has likely been deleted if you use Terraform, for example.)

5. It's too early to have very large configurations yet. But there are techniques we can borrow from other domains - nesting, for example, or layers. We're working on the fundamentals first, and then we will deal with scale.

Great questions!

Yep. If you go to https://systeminit.com and click "Sign up", you can use our launcher to run a build directly.

We've got a fairly large monorepo, with code primarily in Rust, Typescript and PgSQL. We wanted something that would scale as we grew into things like remote execution and build farms, but that would let us be pragmatic in the meantime. Buck2 fit the bill at the time we needed to solve the problem. We also needed it to understand cross language dependencies.

One of the great things about it is that our CI system uses BXL to automatically generate pipelines on the fly from impacted code, taking into account dependencies. So things generally move as quickly as possible through the system.

It's been real work to adopt, but the upside for us has been worth it.

We've been planning to open source it this way for the better part of a year. It just so happened that we were ready to open it up right after the Hashicorp folks made their decision. No intentional timing.

You can see more on our approach here: https://www.systeminit.com/open-source/

Slave to the Grind, without question.