Self-Hosted AI on Alfero Chingono

How I Wired Signal and Microsoft Teams into a Custom OpenClaw Image

Sun, 15 Mar 2026 13:00:00 +0000

In the first post I explained why I wanted Docker as the foundation. This one is the next practical problem: how to get OpenClaw talking to Signal and Microsoft Teams without turning the host machine into a dependency junk drawer.

The short version is that I ended up building a custom image because the base runtime got me close, but not all the way there.

Signal and Teams were different kinds of problems

Signal and Teams pushed on different parts of the system.

Signal is much more of a runtime-tooling problem.

You need a working Signal CLI runtime in the container and a persistent place to keep Signal state. If the container can send Signal messages but the identity disappears on rebuild, you have not actually solved the problem.

Teams is more of a Node/runtime integration problem.

It needs the right hosting support in the image, the right webhook port exposed, and the right application credentials sitting in OpenClaw config so the bot framework side can talk to Microsoft properly.

I didn’t want to solve those two things in two completely different operational styles.

So I chose one image and one compose layout that could support both.

Why I did not stop at the base OpenClaw image

The base OpenClaw image was a good starting point, but I needed more in the environment:

signal-cli-native installed in the container
GitHub CLI and SSH tooling for the agent’s repo workflows
an extra Node modules path for additional runtime packages
a clean way for both the gateway container and the CLI container to share the same capabilities

That led to a custom image tagged locally as openclaw-local:teams.

The name reflects where I started operationally, but the important part is not the tag. The important part is that the image became the place where I declared, very explicitly, “this is the OpenClaw runtime I actually depend on.”

How I handled Signal

For Signal, the key decision was to keep the runtime inside the image and the account state outside it.

The image installs signal-cli-native, which gives the container the actual tool it needs to send and receive Signal messages.

Then the compose file mounts the Signal data directory into:

1

/home/node/.local/share/signal-cli

That was the right split for me:

the image owns the executable
the volume owns the durable Signal identity

This matters more than it sounds.

If the image knows how to run Signal but the identity is trapped inside a replaceable container layer, every rebuild becomes risky. If the state is mounted and durable, rebuilds are much less dramatic.

On the OpenClaw side, the Signal channel is configured with pairing and allowlists so the bot is not just open to the world. That let me keep Signal useful without letting it become an uncontrolled ingress point.

How I handled Teams

Teams had a different shape.

The container needed the extra Node package support for the Microsoft hosting layer, and the gateway needed to expose the Teams webhook port. In my setup that means port 3978 is published by the gateway container so the remote edge can forward /api/messages traffic back to the local OpenClaw runtime.

The actual Teams app credentials live in OpenClaw config, not in the image. That’s exactly where I want them.

The image should describe runtime capability.

The config should describe environment-specific identity.

That boundary kept the setup much easier to move, rebuild, and reason about.

One image, two operational benefits

Using the same custom image for both gateway and cli gave me two benefits I really wanted.

First, it removed “works in one container but not the other” drift.

If the gateway can use the runtime, the CLI can too. If the CLI can inspect or patch something, it is doing so in the same environment the gateway actually uses. I’ve learned to value that kind of consistency a lot.

Second, it let me keep the OpenClaw-specific runtime tweaks in one place:

the extra Node modules path
the installed system packages
Signal CLI
GitHub CLI
pnpm-prepared extras

It’s a much nicer maintenance story than trying to remember which bits live on the host, which belong to the container, and which only exist in some forgotten shell session.

The compose file completed the picture

The image by itself was not enough. The compose file is what turned it into a working system.

That is where I defined the things that make the setup feel real:

mounted OpenClaw config
mounted workspaces
mounted Signal data
shared access to source repositories
local Ollama dependency
editor access
network sharing between the gateway and CLI

This is one reason I still like Docker Compose for personal infrastructure. It doesn’t just run containers. It describes the operating assumptions of the stack in one place.

The setup was already hinting at the routing story

Even at this stage, there was a lesson hiding in plain sight: getting the channels working is the easy part. Once one runtime can talk to Signal and Teams, the questions come quickly — which agent answers where, what state belongs to which workspace, how does a background task find its way back to the right chat. That’s where the series goes next.

Next in the series: Inside the Dockerfile Behind My OpenClaw Gateway.

Why I Run OpenClaw in Docker on My Own Machine

Thu, 05 Mar 2026 09:00:00 +0000

This is the first post in a short series on how I run OpenClaw. It sits earlier than the rest because it is really about the initial Docker Compose setup, before Signal and Teams entered the picture.

I didn’t choose Docker because it’s fashionable. I chose it because I wanted the boring things to stay boring.

I wanted repeatability more than cleverness

OpenClaw in my setup is not just “one process on one machine.”

It’s a local agent gateway, a browser-based editor, an Ollama runtime for local models, a CLI container, persistent state, channel integrations, and a reverse tunnel that exposes selected services through a remote nginx entry point.

That’s already enough moving parts that I didn’t want to manage them as a pile of host-level installs.

I have done that sort of thing before. It works right up until:

one package wants a different runtime version
one upgrade changes behavior in a way you didn’t expect
one machine setup detail becomes tribal knowledge
one rebuild turns into a half-day archaeology project

Docker was the easiest way to say: this stack should come up the same way every time.

I wanted the odd dependencies contained

The biggest reason I didn’t want a host-first install was that OpenClaw was going to talk to real channels.

That meant the environment needed more than just “run the app.”

It needed things like:

signal-cli-native for Signal
extra Node modules for the Teams side
GitHub CLI and SSH tooling because the agent does real repo work
a stable place for OpenClaw config, workspace state, and channel data

None of that is impossible to manage directly on the host. I just didn’t want those concerns smeared across the machine.

I wanted the container image to be the integration boundary. That gave me a much cleaner mental model:

the host provides Docker, storage mounts, and network access
the image defines the runtime and channel dependencies
compose defines how the services fit together

That boundary is much easier to reason about when something breaks.

I still wanted persistent state

One thing I don’t like about naive container setups is when everything becomes disposable except the part you accidentally needed.

I didn’t want that here.

So the setup is intentionally a mix of ephemeral runtime and durable mounted state.

The important state lives outside the container:

OpenClaw config and session state
agent workspaces
Signal data
Ollama model data

I can rebuild or replace the image when I need to, but I don’t lose the identity of the system every time I do it. The agents still have their workspaces. The channel state is still there. The local models are still there.

That’s the behavior I wanted from the start.

Compose matched the shape of the system

The Docker Compose layout also ended up matching how I think about OpenClaw operationally.

I’m not really running “one container.” I’m running a small local AI gateway stack:

gateway for the main OpenClaw runtime and channel/webhook entry points
cli for interactive management using the same image and runtime assumptions
editor for browser-based VS Code access
ollama for local inference
ollama-init to pull the local models once and get out of the way

That separation is useful.

The gateway owns the channel-facing behavior. The CLI shares the network namespace so it can talk to the gateway naturally. The editor stays focused on workspace access. Ollama remains local and isolated. Nothing here feels overloaded.

Running it locally did not mean exposing it sloppily

One reason I like this architecture is that it keeps the heavy lifting on my own machine while still letting me expose selected services in a controlled way.

The public entry point is not “open every container port to the internet.”

Instead, the local stack stays behind Docker, and a reverse SSH tunnel forwards only the ports I explicitly want exposed to a remote VM. nginx on that VM handles TLS termination, routing, and upstream auth.

That design worked well with Docker because it kept the local machine focused on running the real services while the remote VM handled the public edge concerns.

If I’d built this out of ad hoc host installs, I’d probably have ended up with a messier boundary between “local runtime” and “public ingress.”

The trade was absolutely worth it

Docker does add a little ceremony.

You have to think about volumes. You have to think about ports. You have to think about image contents and rebuilds. And once you start adding channel integrations, that image becomes part of the product, not just part of the packaging.

But for this kind of system, I think that is the right trade.

I would much rather spend time shaping one explicit container image and one compose stack than wonder which random host package made the environment drift.

For me, Docker made OpenClaw feel less like a clever experiment and more like an actual service I could live with.

Next in the series: How I Wired Signal and Microsoft Teams into a Custom OpenClaw Image.