Evan Lin for Google Developer Experts

Posted on May 2 • Originally published at evanlin.com on May 2

GCP Hands-on: Deploying OpenAB - Building a Gemini ACP Bridge for Telegram on GCE

#ai #gemini #googlecloud #tutorial

Background

Recently, in order to enable AI coding assistants (such as Claude Code or Gemini CLI) to be used directly on chat platforms, I started researching OpenAB. This is a powerful bridge that can connect Slack, Discord, or Telegram to CLI tools that comply with the ACP (Agent Client Protocol) standard.

This article documents the complete practical process of deploying OpenAB on Google Cloud, specifically how to bypass authentication restrictions, handle Telegram's HTTPS requirements, and resolve path and permission issues in containerized deployments.

OpenAB Reference Documentation: https://openabdev.github.io/openab/
OpenAB Repo: https://github.com/openabdev/openab

Deployment Decision: Why GCE instead of Cloud Run?

Although Cloud Run is my first choice, when dealing with OpenAB, Google Compute Engine (GCE) is the best solution. There are two reasons:

Stateful Session: OpenAB will start a child process (such as Gemini CLI) for each conversation thread. These processes must reside for a long time to maintain the conversation context. Cloud Run's automatic scaling mechanism will kill these processes, leading to conversation interruption.
Authentication Persistence: The AI CLI's Token needs to be stored on the local disk. GCE, combined with Persistent Disk, can ensure that the login status does not disappear after restarting.

Practical Steps: Step-by-Step Deployment Process

Step 1: Writing an Automated Startup Script

To standardize the deployment, we wrote a setup-openab.sh. Its core task is to install Docker, create persistent directories, and dynamically generate config.toml.

The most critical part is the custom Docker Image. Since the official OpenAB image does not necessarily include all AI tools, we install Node.js and @google/gemini-cli on-site through Dockerfile:

FROM ghcr.io/openabdev/openab:latest
USER root
RUN apt-get update && apt-get install -y curl && \
    curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \
    apt-get install -y nodejs && \
    npm install -g @google/gemini-cli
USER 1000

Step 2: Using gcloud to Create a GCE Instance

We chose the e2-medium specification and passed sensitive information (such as Bot Token) through Metadata to avoid hardcoding it in the script.

gcloud compute instances create openab-server \
    --project=your-project-id \
    --zone=asia-east1-b \
    --machine-type=e2-medium \
    --image-family=debian-11 \
    --image-project=debian-cloud \
    --metadata-from-file startup-script=setup-openab.sh \
    --metadata=tg_bot_token=YOUR_BOT_TOKEN

Step 3: Configuring the Gemini API Key

Unlike Kiro, which requires interactive login, gemini-cli can directly read environment variables. We inject the API Key into OpenAB's config.toml to make it run automatically in the background:

[agent]
command = "gemini"
args = ["--acp"]
env = { GEMINI_API_KEY = "AIzaSy..." }

Step 4: Using Cloudflare Tunnel to Solve HTTPS Requirements

Telegram Webhook strictly requires HTTPS. Instead of setting up a complex Nginx + SSL, I chose to use Cloudflare Quick Tunnel:

Run on VM: cloudflared tunnel --url http://localhost:8080.
Get a randomly generated HTTPS URL.
Register Webhook: curl "https://api.telegram.org/bot<TOKEN>/setWebhook?url=<CF_URL>/webhook/telegram&secret_token=<SECRET>"

Blood and Tears in the Migration Process: Technical Summary

During the deployment process, we debugged several times, and here are the three major "pits" summarized:

Pitfall 1: Confusion of Image Sources

At first, I tried to Pull openabdev/openab from Docker Hub, but it always failed. Finally, I found that the current stable image of the project is placed in GitHub Container Registry (GHCR).

Solution: You must use ghcr.io/openabdev/openab:latest.

Pitfall 2: Hardcoded Configuration Path

OpenAB's Dockerfile expects the configuration file path to be /etc/openab/config.toml. I initially mounted it to /app/config.toml, which caused the container to crash immediately after startup and report an error.

Solution: Correct the Docker Volume mount path to /etc/openab/config.toml.

Pitfall 3: Security Secret Token Verification Failed

Even if the URL is correct, Telegram messages are still rejected by the Gateway. The log shows invalid or missing secret_token.

Reason: openab-gateway generates an internal checksum to prevent illegal requests.
Solution: You must extract the Token from the Gateway container and pass it as the secret_token parameter when setWebhook.

Summary: The Perfect AI Bridging Solution

Through this architecture, I successfully built a fully self-hosted, secure, and efficient AI assistant on GCP. It does not rely on expensive subscriptions, but directly utilizes Gemini's API capabilities and uses Telegram as the interaction interface.

If you also want to set up a dedicated ACP bridge on the cloud, this combination of GCE + Docker + Cloudflare Tunnel will be the most balanced and stable choice.

DEV Community