alongub

The main difference is granularity. Terraform runs a plan and applies it as a batch. If something fails, you re-run apply and it retries from the last saved state... but that state is per-resource, not per-API-call.

Alien tracks state at the individual API call level. A single resource creation might involve 5-10 API calls (create IAM role -> attach policy -> create function -> configure triggers -> set up DNS...). If it fails at step 7, it resumes from step 7. Terraform would retry the entire resource.

The other difference is that Alien runs continuously, not as a one-shot apply. It's a long-running control plane that watches the environment, detects drift, and reconciles. Terraform assumes you run it, it converges, and then nothing changes until you run it again.

Thanks so much! If you have any other ideas, I'd really appreciate it if you could shoot them my way (alon AT alien dot dev)

Fair point

Alien is basically a huge state machine where every API call that mutates the environment is a discrete step, and the full state is durably persisted after each one.

If something fails mid-update, it resumes from exactly where it stopped. You can also point a deployment to a previous release and it walks back. This catches and recovers from issues that something like Terraform would just leave in a broken state.

For on-prem: we're working on Kubernetes as a deployment target (e.g. bare metal OpenShift)

> Would you support simpler deployment targets, like on premises VMs etc?

https://github.com/alienplatform/alien/blob/main/crates/alie... :)

This is true even with fully-managed SaaS though. There are always users who don't want the new UI, the changed workflow, the moved button. But the update mechanism isn't really the problem IMO, feature flags and gradual rollouts solve this much better than version pinning

At least they didn't ask you to TeamViewer into a Windows Server 2012 box and open Event Viewer..

Both are real risks. But supply chain attacks exist whether you self-host or not... you're still running the vendor's code either way. The question is whether you also want that code to stay up to date and properly managed, or drift silently.

> Although unfortunately, we can't maintain _any_ connection back to our servers. Pull or push, doesn't matter.

We're working on something for this! Stay tuned.

In practice, unmanaged self-hosting is often less secure, because you end up with outdated versions, unpatched vulnerabilities, and no one responsible for keeping things healthy.

More and more enterprise CISOs are starting to understand this.

The model here is closer to what companies like Databricks already do inside highly regulated environments. It's not new... it's just becoming more structured and accessible to smaller vendors.

Right, and that's when you do control the environment. Now imagine debugging that when it's your customer's infra, you have no access, and you're relying on them to copy-paste logs on a Zoom call.

It's not RCE. The commands are predefined RPCs written into the deployed code. Customers can review and approve them. Trust between the vendor and the customer is still required and Alien doesn't make it unnecessary.

It's heavily inspired by Databricks' deployment model. And you're right that it's not "execute arbitrary commands". Commands are predefined functions in the deployed code that the developer defines upfront and customers can review.

The metrics/logs part is also core to Alien... telemetry flows back to the vendor's control plane so you actually have visibility into what's running.

AgentMail looks amazing!

Exactly

Foyer is great!

Wow, this looks fantastic!

There's a really neat pattern for building stateful apps on Postgres that can handle millions of entities concurrently.

Traditionally you'd need Kafka / RabbitMQ / other external components. But FOR UPDATE SKIP LOCKED basically make these redundant for some types of applications.

I found it particularly useful for building LLM-based agents that can transition between different states.

I created a short video to demonstrate the concept: https://youtu.be/VvDHi-H0Jck?si=WuUhUyIOuZ6jj8BO

Hope you find it useful!

For sure, this is definitely planned!

I wrote a tool that helps estimate K8s costs by simulating K8s clusters. You write your pods in a simple DSL and it runs kube-scheduler without actual nodes behind the scenes.

It's still really basic but I'd love to hear your feedback!

https://github.com/aporia-ai/kubesurvival

Not exactly a channel, but a few weeks ago I did a live coding session on how to build an ML platform from scratch (the stuff you need to get ML models to production):

https://youtu.be/s8Jj9gzQ3xA

I didn't look into the product itself, but the idea is absolutely genius.

You should build an 'app store' for bots, just like https://wordpress.org/plugins/.