Has anyone tried running Claw on a local air-gapped network? The setup docs are fantasy.

Alright, I've just wasted the better part of two days trying to get Claw's "Enterprise Edge" platform running in our secure development environment, which is fully air-gapped. Their much-hyped blog post about "on-premises deployment simplicity" is, frankly, a fantasy. The documentation assumes you have a live egress connection for half the setup process, and their artifact repository is a black box.

Here's the reality they don't tell you:
* The `clawctl init --offline` flag does pull some binaries, but it silently tries to phone home to `registry.claw.io` for what they call "core experience modules," which are just Helm charts wrapped in their own proprietary packaging layer.
* Their "offline bundle" you can download is a 12GB tar file that unpacks into a manifest of other tar files. The instructions then tell you to run a script that expects to mount to a local Docker registry, but the script has hard-coded paths that fail if your internal registry uses a self-signed cert (which, of course, ours does).
* The configuration for the management plane is a 2000-line YAML values file where key components like the internal message queue and the metrics collector are tied to undocumented resource requests. We had to brute-force modify memory limits after the pods kept getting OOMKilled.

The core problem isn't even the complexity—it's the false premise. They've taken Argo CD, a few operators, and a dashboard, wrapped it in their own tooling, and then made the wrapper dependent on their own infrastructure. It defeats the entire point of an air-gapped install.

I had to manually mirror everything. The process looked nothing like their docs. It was more like:
1. Scrape all images from their bundle manifest using `skopeo`.
2. Push to our internal registry, rewriting all tags because their format used a naming convention our registry proxy rejected.
3. Write a custom Terraform module to deploy the base Kubernetes resources because their `clawctl` bootstrap kept failing. Example of the kind of hack I needed:

```hcl
# This is just to get the prereqs they assume you have
resource "kubernetes_namespace" "claw_core" {
metadata {
name = "claw-core"
labels = {
"security-tier" = "managed"
}
}
}

# Had to manually set up the PVCs they dynamically provision in their script
resource "kubernetes_persistent_volume_claim" "claw_postgres" {
metadata {
name = "postgres-data"
namespace = kubernetes_namespace.claw_core.metadata[0].name
}
spec {
access_modes = ["ReadWriteOnce"]
resources {
requests = {
storage = "50Gi"
}
}
storage_class_name = "local-path" # Because we can't use cloud provisioners
}
}
```

So, the "so what": If you're evaluating Claw for a disconnected environment, budget at least a week of engineering time just to get past the packaging and bootstrap. You're essentially reverse-engineering their platform to re-platform it onto your own standards. The value prop collapses when you realize you're doing the heavy lifting anyway.

Has anyone else battled through this? Did you find a workaround, or did you just abandon ship and go back to assembling your own stack with Argo and Prometheus? I'm at the point where maintaining our own Helm chart library seems less painful.