rmBug Gateway

The rmBug Gateway is a self-hosted database proxy that sits on your infrastructure. Your engineers connect through it using identity-based access — no shared credentials, no VPN required.

Quick start

docker run -d \
  -e RMBUG_GATEWAY_ACCESS_KEY=rmb_gw_your_key_here \
  -v rmbug-data:/var/lib/rmbug \
  ghcr.io/rmbug/gateway:latest

The gateway registers itself with the rmBug control plane and starts accepting connections. Get your access key from the rmBug dashboard under Settings → Gateways.

Docker Compose

services:
  gateway:
    image: ghcr.io/rmbug/gateway:latest
    restart: unless-stopped
    environment:
      RMBUG_GATEWAY_ACCESS_KEY: ${RMBUG_GATEWAY_ACCESS_KEY}
    volumes:
      - rmbug-data:/var/lib/rmbug

volumes:
  rmbug-data:

Environment variables

Variable	Required	Default	Description
RMBUG_GATEWAY_ACCESS_KEY	Yes	—	API key from the rmBug dashboard (rmb_gw_...)
RMBUG_GATEWAY_FQDN	No	localhost	Your gateway's public hostname. Set this when deploying with a public domain
RMBUG_RELAY_FQDN	No	—	Override the relay FQDN (auto-discovered from the control plane if not set)
RMBUG_STORAGE_URI	No	sqlite:///var/lib/rmbug/gateway.db	Audit log storage. SQLite (default), PostgreSQL (postgres://...), or MySQL (mysql://...)
RMBUG_TLS_LISTEN_PORT	No	8443	TLS port inside the container. Map to 443 externally
RMBUG_AUDIT_BUFFER_SIZE	No	1000	Max audit events buffered in memory before flushing
RMBUG_AUDIT_FLUSH_INTERVAL	No	10s	How often buffered audit events are written to storage

Supported databases

Database	Versions
PostgreSQL	14, 15, 16, 17, 18
MySQL	8.0+

How it works

The gateway forwards database traffic transparently after authentication — it doesn't parse the database protocol. This means prepared statements and every other protocol feature work exactly as they would with a direct connection.

When an engineer connects:

1. Their rmBug agent sends a JWT to the gateway
2. The gateway validates the JWT against the control plane
3. The gateway opens a connection to the target database using the stored credentials
4. Traffic flows transparently in both directions

Audit log persistence

The gateway stores audit logs locally using SQLite by default (/var/lib/rmbug/gateway.db). If you don't mount a persistent volume, audit logs are lost when the container restarts.

There are three ways to make audit logs durable:

Option 1: Named Docker volume (simplest)

docker run -d \
  -e RMBUG_GATEWAY_ACCESS_KEY=rmb_gw_your_key_here \
  -v rmbug-data:/var/lib/rmbug \         # ← persistent named volume
  ghcr.io/rmbug/gateway:latest

Option 2: External PostgreSQL

docker run -d \
  -e RMBUG_GATEWAY_ACCESS_KEY=rmb_gw_your_key_here \
  -e RMBUG_STORAGE_URI=postgres://user:pass@db-host/gateway \
  ghcr.io/rmbug/gateway:latest

Option 3: External MySQL

docker run -d \
  -e RMBUG_GATEWAY_ACCESS_KEY=rmb_gw_your_key_here \
  -e RMBUG_STORAGE_URI=mysql://user:pass@db-host/gateway \
  ghcr.io/rmbug/gateway:latest

PostgreSQL or MySQL are the right choice if you're running multiple gateway replicas — they share a single audit store. SQLite with a persistent volume works fine for a single instance.

Without a persistent store, the gateway still works — engineers can still connect, and connections are still logged in the rmBug control plane. Only the local audit copy is lost on restart.

Upgrading

docker pull ghcr.io/rmbug/gateway:latest
docker stop <container> && docker rm <container>
# re-run with the same docker run / compose command

The volume persists across upgrades, so audit history is preserved.

Full documentation

→ rmbug.com/docs/gateway