> 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 could trigger that export on our request, or (ideally) as part of the support ticketing process. Then our engineers can analyze async. This can be a ton of data though, so we're trying to figure out what to compress and how. We also have the challenge of figuring out how to scrub logs of any potentially sensitive information. Even IDs, file names, etc that only matter to customers.
I worked for a few years on an on-premise deployment of a system that was otherwise SaaS. Many enterprise customers simply won’t allow something like this - particularly big financials, aviation, healthcare etc.
Realistically, the game ends up being - see what you can get away with until someone notices. Given that, you might want to rename the product to something more boring than “Alien”.
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.
IIUC this kind of thing is usually called “managed deployment.” Minio used to have a slick implementation of this, and I think databricks does as well. Usually it’s less “execute arbitrary commands on customer hosts,” and more “send metrics and logs to shared repository and send RPCs to customer deployment”
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.
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.
> 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 could trigger that export on our request, or (ideally) as part of the support ticketing process. Then our engineers can analyze async. This can be a ton of data though, so we're trying to figure out what to compress and how. We also have the challenge of figuring out how to scrub logs of any potentially sensitive information. Even IDs, file names, etc that only matter to customers.
I worked for a few years on an on-premise deployment of a system that was otherwise SaaS. Many enterprise customers simply won’t allow something like this - particularly big financials, aviation, healthcare etc.
Realistically, the game ends up being - see what you can get away with until someone notices. Given that, you might want to rename the product to something more boring than “Alien”.
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.
agreed, this architecture is a non-starter for many enterprise orgs
Even when you do control the environment, infra isn’t as stable as people think.
Same VPS, same config, but under sustained load you’ll see latency creep or throughput drift depending on the host / routing / neighbors.
Short tests almost never show it — only shows up after a few minutes.
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.
IIUC this kind of thing is usually called “managed deployment.” Minio used to have a slick implementation of this, and I think databricks does as well. Usually it’s less “execute arbitrary commands on customer hosts,” and more “send metrics and logs to shared repository and send RPCs to customer deployment”
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.
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.