Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Alien – Self-hosting with remote management (written in Rust)

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#41

Post by alongub »

pruthviraja wrote: post #37
alongub wrote: post #28

Earlier quoted context omitted.

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…

i think the durable state machine approach is smart...that resume from where it stopped behavior is a big deal during incident response when you really dont want to rerun an entire deployment just because one step failed. K8s as a deployment target would be huge especially for the on-prem enterprise crowd. Will definitely keep an eye on that

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)

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#42

Post by rendaw »

alongub wrote: post #28
pruthviraja wrote: post #27

Interesting approach. The managed self-hosting gap is real..we have run into this exact pain point with kubernetes based deployments where customers modify their cluster configs and things break silently. If I may ask how does Alien handle rollback if an update fails in a customer environment?is there any plan for on-prem/bare metal support beyond the big three clouds?

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…

How is this different from Terraform? Generally if something fails during a TF apply it saves the state of all the stuff that worked and just retries the thing that failed when you next run it. And reverting your TF stack and doing apply again should walk changes back.

There are specific things where that's not possible, and there are bugs, but it doesn't seem like what you said unless you meant that you just support a limited subset of resources that are known to be robust to reverts? But that's a fairly different claim.

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#43

Post by alongub »

rendaw wrote: post #42
alongub wrote: post #28

Earlier quoted context omitted.

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…

How is this different from Terraform? Generally if something fails during a TF apply it saves the state of all the stuff that worked and just retries the thing that failed when you next run it. And reverting your TF stack and doing apply again should walk changes back. There are specific things where that's not possible, and there are bugs, but it doesn't seem like what you said unless you meant that you just support…

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.

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#44

Post by lelanthran »

nodesocket wrote: post #13
nickmonad wrote: post #11

> So you're stuck debugging a system you don't control, through screenshots and copy-pasted logs on a Zoom call. This is very real. I work with a deployment that operates in this fashion. Although unfortunately, we can't maintain _any_ connection back to our servers. Pull or push, doesn't matter. The goal right now is to build out tooling to export logs and telemetry data from an environment, such that a customer cou…

I also used to work with on-premise installs of Kubernetes and their “security” postures prevented any in-bound access. It was a painful process of requesting access, getting on a zoom call and then controlling their screen via a Windows client and putty. It’s was beyond painful and frustrating. I tried to pitch using a tool like Twingate which doesn’t open any inbound ports, can be locked down very tight using SSO,…

For most enterprises there's too many jobs on the line to replace windows.

The people who know where to click and which dialog will pop up and when to click next are never going to agree to replace their non-automatable windows servers with fully automatable linux servers.

I mean, we're talking about a demographic that can't use ssh, never been on a platform using system package managers, and has little to no ability to version system changes.

They do all that manually.

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#45

Post by cassianoleal »

alongub wrote: post #5
cassianoleal wrote: post #2

RCE into my environment? No, thanks.

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 may not be arbitrary code but it's still remote code execution.

The service provider has direct access to my infrastructure. It's one supply chain attack, one vulnerability, one missed code review away from data exfiltration or remote takeover.

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#46

Post by irickt »

munksbeer wrote: post #21

I very seldom, if ever, see a "Show HN" title with a suffix of "written in Java" or "written in python" or "written in Go". "Written in Rust" seems to be a very popular thing to add. My assumption is that people know it will get the thread more visibility?

The signal works both ways. "Written in Java" would save a lot of clicks. So the Java author may omit the label for the same reason. /s

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#47

Post by armagnac2 »

cassianoleal wrote: post #45
alongub wrote: post #5

Earlier quoted context omitted.

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 may not be arbitrary code but it's still remote code execution. The service provider has direct access to my infrastructure. It's one supply chain attack, one vulnerability, one missed code review away from data exfiltration or remote takeover.

what better alternative do you have? It's either you go full SaaS, which means you rely 100% on the vendor, or work like 20 years ago with fully on prem. BYOC is the fine balance imo, that requires proper infra and implementation.

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#48

Post by pruthviraja »

alongub wrote: post #41
pruthviraja wrote: post #37

Earlier quoted context omitted.

i think the durable state machine approach is smart...that resume from where it stopped behavior is a big deal during incident response when you really dont want to rerun an entire deployment just because one step failed. K8s as a deployment target would be huge especially for the on-prem enterprise crowd. Will definitely keep an eye on that

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)

For sure.. Thank you

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#49

Post by i_think_so »

tanki wrote: post #30

Such a big pain, I’ve experienced those issue first hand in my last two startups and it took so much time and effort Super cool product, I’ve gotta try it

Account created yesterday, exactly one comment.

Meta: I presume youngish accounts like mine (who can't downvote yet) have no role to play in policing astroturfing like this, correct?

Re: Show HN: Alien – Self-hosting with remote management (written in Rust)

#50

Post by i_think_so »

alongub wrote: post #43
rendaw wrote: post #42

Earlier quoted context omitted.

How is this different from Terraform? Generally if something fails during a TF apply it saves the state of all the stuff that worked and just retries the thing that failed when you next run it. And reverting your TF stack and doing apply again should walk changes back. There are specific things where that's not possible, and there are bugs, but it doesn't seem like what you said unless you meant that you just support…

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...). I…

Speaking of granularity, I noticed that the 2 states of a resource seem to be:

> Frozen: Alien can only monitor it. Created once during setup, then Alien has no permissions to modify or delete it. > Live: Alien can manage it from your cloud. Push code updates, roll config changes, redeploy — without the customer's involvement.

Is that really all? What about something like "Alien can run these 37 maintenance and debugging commands but cannot touch the firewall or modify routes or change any other access methods to internal resources"?

(I'm looking at https://www.alien.dev/docs/how-alien-works here.)

Post reply on HN