← Back to Skills Marketplace
superworldsavior

Localhost Bridge

by Erwan Lee Pesle · GitHub ↗ · v2.0.0
cross-platform ⚠ suspicious
504
Downloads
0
Stars
0
Active Installs
5
Versions
Install in OpenClaw
/install localhost-bridge
Description
Bridge Docker containers to host localhost services via socat. Solves the #1 networking issue in containerized AI agent deployments: containers can't reach s...
README (SKILL.md)

localhost-bridge — Connect containers to host localhost services

⚠️ Security & Privileges

This skill requires host-level privileges. It must be reviewed and executed manually by an administrator — never autonomously by an agent.

What it does on the host:

  • Creates a systemd service (persistent across reboots) that forwards traffic from a Docker bridge IP to localhost
  • Adds a UFW firewall rule scoped to a specific Docker bridge interface
  • Requires sudo, Docker daemon access, and socat from your distro's official package repository

Before running any command:

  1. Review the generated /etc/systemd/system/socat-\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>.service file — confirm ExecStart binds only to the intended Docker bridge IP (172.x.x.1), never 0.0.0.0
  2. Review the UFW rule — confirm it targets the correct br-\x3CID> interface and port
  3. After setup, verify the port is NOT reachable from the public network: curl --connect-timeout 2 http://\x3CPUBLIC_IP>:\x3CPORT>/ must fail
  4. Test from inside a container before deploying widely

Do not grant an automated agent permissions to run these commands without human approval.


The Problem

A service on the host listens on 127.0.0.1 (AI gateway, MCP server, Ollama, database...). A Docker container needs to reach it. localhost inside the container points to the container itself, not the host. Requests either timeout silently (firewall drops packets) or get connection refused.

The Solution

socat listens on the Docker bridge gateway IP and forwards to host loopback. Combined with a scoped firewall rule, this gives containers access without exposing the service externally.

Setup (run manually as admin)

1. Find the Docker bridge gateway IP

# For a specific container
docker inspect \x3Ccontainer_name> --format '{{json .NetworkSettings.Networks}}' \
  | python3 -c "
import json,sys
d = json.load(sys.stdin)
for net, info in d.items():
    print(f'{net}: gateway={info[\"Gateway\"]}')"

2. Create a systemd service

Replace \x3CGATEWAY_IP>, \x3CPORT>, \x3CSOURCE_NETWORK>, and \x3CTARGET_SERVICE> with your values.

Naming convention: socat-\x3Csource_network>-\x3Ctarget_service>-\x3Cport> — source network is the Docker network (consumer), target service is the host service. Self-documenting.

Examples: socat-bridge-gateway-18789, socat-windmill_default-gateway-18789, socat-bridge-ollama-11434

Review the ExecStart line before enabling — confirm it binds to the Docker bridge IP only.

sudo tee /etc/systemd/system/socat-\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>.service > /dev/null \x3C\x3C 'EOF'
[Unit]
Description=Socat bridge: \x3CSOURCE_NETWORK> -> \x3CTARGET_SERVICE>:\x3CPORT>
After=network.target docker.service

[Service]
Type=simple
ExecStart=/usr/bin/socat TCP-LISTEN:\x3CPORT>,bind=\x3CGATEWAY_IP>,fork,reuseaddr TCP:127.0.0.1:\x3CPORT>
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

# Review the file before enabling:
cat /etc/systemd/system/socat-\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>.service

sudo systemctl daemon-reload
sudo systemctl enable --now socat-\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>

3. Add firewall rule (MANDATORY)

Without this, socat listens but packets from the container are silently dropped — causing 30-second timeouts with no error.

Review the bridge ID before applying — a wrong ID can expose services.

# Find the Linux bridge interface for the Docker network
BRIDGE_ID=$(docker network inspect \x3Cnetwork_name> --format '{{.Id}}' | cut -c1-12)

# Verify this is the right bridge
ip link show br-${BRIDGE_ID}

# Allow traffic only on that bridge interface
sudo ufw allow in on br-${BRIDGE_ID} to any port \x3CPORT> proto tcp comment "\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>"

4. Verify security

# MUST succeed (from inside a container)
docker exec \x3Ccontainer_name> curl -s --connect-timeout 5 http://\x3CGATEWAY_IP>:\x3CPORT>/

# MUST fail (from the public network)
curl --connect-timeout 2 http://\x3CPUBLIC_IP>:\x3CPORT>/

Multi-Network Workers

A container can be on multiple Docker networks. Each has its own bridge IP. You need a socat instance + firewall rule for each network the container uses. In practice, one network is usually enough.

Check all networks: docker inspect \x3Ccontainer> --format '{{json .NetworkSettings.Networks}}'

Common Use Cases

Host service Container client Default port
AI gateway (OpenClaw, LiteLLM) Workflow orchestrator (Windmill, n8n) 18789
MCP server Dockerized agent varies
Ollama RAG pipeline, agent 11434
PostgreSQL API server 5432
Redis Any containerized app 6379

Troubleshooting

Symptom Cause Fix
30s timeout, no error Firewall dropping packets Add UFW rule on the bridge interface
Connection refused socat not running systemctl status socat-\x3CSOURCE_NETWORK>-\x3CTARGET_SERVICE>-\x3CPORT>
Works then stops after Docker restart Bridge IP changed Check new gateway IP, update socat bind
socat won't start after reboot Docker not ready Ensure After=docker.service in unit file

Alternatives

Depending on your security posture, consider:

  • Docker host networking (network_mode: host) — simpler but removes all container network isolation
  • Running socat inside a minimal privileged container — avoids host-level systemd changes
  • Configuring the host service to bind to the Docker bridge IP directly — no socat needed, but the service must support custom bind addresses
  • host.docker.internal (Docker Desktop) — works on Mac/Windows, not reliably on Linux

Prerequisites

Install socat from your distro's official package repository:

sudo apt-get install -y socat  # Debian/Ubuntu
sudo dnf install -y socat      # Fedora/RHEL

References

Usage Guidance
This skill appears to implement what it claims (using socat + firewall + systemd to let containers reach host-local services), but it requires high privileges and makes persistent host network changes — do not let an agent run it autonomously. Before installing or following the instructions: (1) only run these commands as a trusted administrator on a controlled host; (2) manually inspect the generated /etc/systemd/system/socat-*.service ExecStart line and confirm it binds only to the intended Docker bridge IP (never 0.0.0.0); (3) inspect the UFW rule and bridge interface name before enabling it; (4) test from inside a container and verify the port is NOT reachable from the public network; (5) prefer documented alternatives (host networking or a scoped privileged container) if you cannot safely manage sudo/systemd/UFW; and (6) ask the skill publisher to update registry metadata to explicitly list required binaries/privileges (sudo, docker, socat) so the privilege requirements are transparent. If you want higher confidence, request an explicit example unit and firewall rule for your environment and confirm there are no steps that would open services to the public internet.
Capability Analysis
Type: OpenClaw Skill Name: localhost-bridge Version: 2.0.0 This skill is classified as suspicious due to its requirement for extensive host-level privileges, including `sudo` access for creating persistent systemd services and UFW firewall rules, and direct Docker daemon access. While the `SKILL.md` documentation is exceptionally transparent, explicitly warning against autonomous agent execution and providing detailed security review steps for human administrators, the inherent power of these commands (e.g., `socat` binding, systemd persistence) means that any misconfiguration or intentional misuse could lead to significant security vulnerabilities, such as exposing internal services. There is no evidence of malicious intent, data exfiltration, or stealthy backdoors; rather, the documentation actively guides secure usage. The prompt injection surface is used to *warn* the agent/user, not to trick them into harmful actions. However, the high-risk capabilities warrant a 'suspicious' classification rather than 'benign'.
Capability Assessment
Purpose & Capability
SKILL.md clearly requires sudo, Docker daemon access, and the socat package to create systemd services and UFW rules on the host. The registry metadata (required binaries/env/config) lists none of these requirements, creating an incoherence between what the skill claims to need and what it actually instructs an admin to do.
Instruction Scope
The runtime instructions are explicit and scoped to the stated purpose (bind socat to a Docker bridge IP, add a scoped UFW rule, create a systemd unit). The doc repeatedly warns that an administrator must review the generated unit and firewall rules before enabling them.
Install Mechanism
This is an instruction-only skill with no install spec or code files — nothing is downloaded or written by the skill itself beyond what an admin runs. That minimizes code-distribution risk.
Credentials
The actions require host-level privileges (sudo to write systemd units, modify UFW) and Docker daemon access. Those privileged requirements are reasonable for the described task but are not declared in the registry metadata, which understates the level of credential/privilege access needed.
Persistence & Privilege
The setup creates persistent system changes (systemd service + UFW rule) which affect host networking. While always:false is correctly set, the platform metadata also allows agent invocation by default; because the SKILL.md warns it must not be run autonomously, there is a policy mismatch — ensure automated agents are NOT given sudo/host access before enabling.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install localhost-bridge
  3. After installation, invoke the skill by name or use /localhost-bridge
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v2.0.0
v2: Updated naming convention socat-source-target-port. Removed ITIL references. Set privileged false.
v1.2.1
Fix: set privileged=false, autonomous=false. Added explicit safety metadata to prevent autonomous execution warnings.
v1.2.0
Updated naming convention: socat-<source_network>-<target_service>-<port>. Removed ITIL references. Self-documenting names.
v1.1.0
Security hardening: declare privileges in metadata, add review-before-running warnings, homepage/source provenance, alternatives section, verify-security step
v1.0.0
Initial publish: socat bridge pattern for Docker containers to reach host localhost services
Metadata
Slug localhost-bridge
Version 2.0.0
License
All-time Installs 0
Active Installs 0
Total Versions 5
Frequently Asked Questions

What is Localhost Bridge?

Bridge Docker containers to host localhost services via socat. Solves the #1 networking issue in containerized AI agent deployments: containers can't reach s... It is an AI Agent Skill for Claude Code / OpenClaw, with 504 downloads so far.

How do I install Localhost Bridge?

Run "/install localhost-bridge" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Localhost Bridge free?

Yes, Localhost Bridge is completely free (open-source). You can download, install and use it at no cost.

Which platforms does Localhost Bridge support?

Localhost Bridge is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Localhost Bridge?

It is built and maintained by Erwan Lee Pesle (@superworldsavior); the current version is v2.0.0.

💬 Comments