It isn't today, but we've built Bottlerocket in a way that it can be extended to work on bare metal or other places outside of AWS. There are a few issues on our github[1][2] that are similar that you're welcome to watch or contribute use cases to.

[1] https://github.com/bottlerocket-os/bottlerocket/issues/841 [2] https://github.com/bottlerocket-os/bottlerocket/issues/1097

Really glad you like our tough (TUF) library!

As far as running in non-AWS contexts, we haven't had time to head down that path yet, but as I mentioned in an earlier post, we've tried to build Bottlerocket in a way that it can be extended to work outside of AWS either as VMs or even bare metal. In fact, a few of the engineers on the team have been playing with getting it running on their RaspberryPi's at home :)

Answering your initial question and this one: Bottlerocket today only runs in EC2, but we've tried to make it flexible enough to run outside of a hypervisor on bare metal in the future (in fact, a few engineers on the team are really excited to get it running on their RaspberryPi's at home; toasters haven't been added to our roadmap yet ;) ).

Bottlerocket has a GNU userland like many other distros. It is just one that is stripped down of many things including removal of interpreters, shells, and package managers.

If you want to explore more deeply, you can enable the admin container and jump into a shell on the host[1] to look at the filesystem and see what Bottlerocket's userspace looks like up close and personal. You can also see a bit more of this debugging/exploration tooling explained in an AWS Partner Blog[2].

[1] https://github.com/bottlerocket-os/bottlerocket#admin-contai... [2] https://aws.amazon.com/blogs/apn/getting-started-with-bottle...

No overlap per se, but we are looking at how to integrate Firecracker as a potential target for "container" launches: https://github.com/orgs/bottlerocket-os/projects/1#card-3386...

Glad you're enjoying them! We have a glossary just in case: https://github.com/bottlerocket-os/bottlerocket/blob/develop... (my personal favorite is Laika, the first dog in space and our pre-init binary)

Honestly, reading the glossary gives me Urbit [1] vibes :(

> bork: A setting generator called by sundog to generate the random seed for updog, determining where the host falls in the update order.

[1]: https://urbit.org/docs/glossary/

Agree. It's cool so long as the number of names is small, and the names actually are a pun on the function and not just e.g. names of planets. If "updog" is what brings something "up" that's a good name.

WiX (windows installer creation) has a multi-phase command line interface where the compiler/linker/.. has different names indicating the order they are applied: candle, light, smoke... Also a working system I guess.

"bork" is dog-talk for "bark", and so something that randomly gets an updog going being named such makes sense too, it's just a slightly more obscure joke.

While our first variant is focused on Kubernetes and EKS, we have designed Bottlerocket in a way that new variants can be built that work with other orchestrators, or even without one (we have ECS support on our roadmap already). Also, we really enjoyed working in Rust for big chunks of this!

> Also, we really enjoyed working in Rust for big chunks of this!

Glad to hear it! Please reach out if you need anything :)

>"While our first variant is focused on Kubernetes and EKS..."

So is the idea that people create a Bottlerocket AMI and use that as their EKS worker node images? Is that correct?

Correct! Or you can spin up one of the AMIs we've already built. You can find current AMIs via public SSM parameters: https://github.com/bottlerocket-os/bottlerocket/blob/develop...