Twingate Custom Connector Container
Problem
The official Twingate connector container is intentionally minimal - no shell, no scripting environment, no first-class hook for custom health checks or observability. That works for most deployments, but customers running connectors in instrumented enterprise environments needed shell access for debugging, a way to add custom health verification logic, and structured resource metrics that could flow into their existing log aggregation stack without spinning up a separate sidecar.
Approach
Built a custom Docker image that wraps the Twingate Linux/systemd connector with three additions: interactive shell access for in-container debugging, a pluggable health check framework that runs any executable dropped into /healthchecks.d/ on a 90-second interval (scripts return 0 for success or non-zero for failure), and a structured resource metrics emitter that writes JSON-formatted CPU, memory, and network I/O metrics to stdout every 60 seconds. The metrics output is designed for direct ingestion by CloudWatch Logs, Azure Log Analytics, and Datadog with no sidecar or additional agent required. The Dockerfile and entrypoint.sh are deliberately kept simple so users can fork and extend.
Outcome
Published under the Twingate-Solutions organization at ghcr.io/twingate-solutions/twingate-custom-connector-container, giving customers and partners a supported path for connector observability without maintaining their own container build pipelines. Bundled docker-compose template gets deployments running quickly, and the health check framework means new monitoring logic is a drop-in change rather than an image rebuild.