Guide: Getting Claw to work with our air-gapped development network.

Alright, let's talk about the special kind of fun that is running a modern, cloud-native dev platform like Claw inside an air-gapped network. Because apparently, some of us still have to deal with the reality of on-prem everything, thanks to "security theater" and legacy compliance frameworks that think the internet is a series of tubes best left unconnected.

Our context: a mid-sized engineering team (~50 devs) working on a monolith-to-microservices transition. Stack is pretty standard Java/Spring and Node.js services, aiming for Kubernetes, with Claw as our intended platform for internal developer portals and backstage functionality. The air-gapped network is a physical reality, not a debate. Self-hosted was the *only* option considered; the phrase "vendor's SaaS offering" gets you a stern look from infrastructure security.

The core challenge with Claw in this environment isn't the main application—it's the ecosystem. Claw, like every modern tool, assumes it can just reach out and hug the internet whenever it wants, primarily for:

* Plugin catalogs (pulling directly from GitHub, npm, etc.)
* Scaffolding templates
* CI/CD integrations that ping external APIs
* Documentation snippets that reference external assets

Here's how we surgically disconnected it from the mothership.

**Phase 1: The Docker Image Heist**
You can't just `docker pull` from Docker Hub. So we stood up a private registry on the air-gapped side and became art smugglers. Using a secured jump host with *limited, audited* external access, we pulled the entire Claw dependency chain. This is a multi-step nightmare because it's never just one image.

```bash
# On the connected machine (not inside the air-gap)
docker pull clawsoftware/claw-backstage:latest
docker save -o claw-backstage.tar clawsoftware/claw-backstage:latest
# Repeat for postgres, redis, and any other upstream dependencies.
# Then physically transfer (yes, with a USB drive) and load on the internal registry host.
docker load -i claw-backstage.tar
docker tag clawsoftware/claw-backstage:latest internal.registry.corp/claw-backstage:latest
docker push internal.registry.corp/claw-backstage:latest
```

**Phase 2: Taming the Plugin Catalog**
The default plugin setup points to ` https://github.com/backstage/backstage/tree/master/plugins`. That's a non-starter. We had to:

* Mirror the specific plugin repos we needed (catalog, scaffolder, techdocs, etc.) to our internal GitLab instance.
* Fork and modify the `app-config.yaml` to point all plugin sources to internal URLs. This means any future updates require a manual sync-and-merge process.
* Pre-build any custom plugins externally, then ship the built artifacts in, as the internal build pipeline lacks public npm access.

**Phase 3: The Scaffolder's Broken Dreams**
The software templates are wonderful, until they reference `fetch:plain` actions that pull from public repositories. Every template action that does an external fetch must be rewritten to use internal equivalents. We ended up creating a set of internal template actions that clone from our mirrored repos. The horror story here was discovering a community template that had three levels of nested external repository references.

**Key Config Snippets:**
In our `app-config.airgap.yaml`, overrides looked like this:

```yaml
app:
baseUrl: https://claw.internal.corp
backend:
baseUrl: https://claw.internal.corp
cors:
origin: https://claw.internal.corp
reading:
allow:
- host: internal.gitlab.corp
integrations:
github:
- host: internal.gitlab.corp
token: ${INTERNAL_GITLAB_TOKEN}
```

**What Works, What Doesn't:**
* Works: The core catalog, basic techdocs (if all assets are internal), static API docs.
* Doesn't Work: Any plugin that phones home for updates. Any community template that hasn't been fully vetted and internalized. The "Explore" features that show trending OSS projects.

The final cost? About three engineer-weeks of careful mapping, manual mirroring, and configuration surgery. The result is a functional Claw instance that feels like it's living in a bunker—which it is. It does the job, but you lose the vibrant ecosystem that makes the platform compelling in the first place. You're not buying a platform anymore; you're adopting a codebase to maintain.

If you're going down this path, budget for a dedicated integration engineer to manage the sync procedures and treat your internal Claw as a forked product, not a managed service. Because it is.