Only accountless tunnels with docker-compose

Hi there,

I was using my cloudflared tunnel for a while using the docker command that’s shown on the page - this worked fined. Now I wanted to move everything into docker-compose files for more easy management and noticed that cloudflared now always creates accountless tunnels:

2022-12-08T07:48:39Z INF Thank you for trying Cloudflare Tunnel. Doing so, without a Cloudflare account, is a quick way to experiment and try it out. However, be aware that these account-less Tunnels have no uptime guarantee. If you intend to use Tunnels in production you should use a pre-created named tunnel by following: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps 2022-12-08T07:48:39Z INF Requesting new quick Tunnel on trycloudflare.com... 2022-12-08T07:48:41Z INF +--------------------------------------------------------------------------------------------+ 2022-12-08T07:48:41Z INF | Your quick Tunnel has been created! Visit it at (it may take some time to be reachable): | 2022-12-08T07:48:41Z INF | https://operates-mongolia-a-apple.trycloudflare.com | 2022-12-08T07:48:41Z INF +--------------------------------------------------------------------------------------------+ 2022-12-08T07:48:41Z INF Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared] 2022-12-08T07:48:41Z INF Version 2022.11.1 2022-12-08T07:48:41Z INF GOOS: linux, GOVersion: go1.19.3, GoArch: arm64 2022-12-08T07:48:41Z INF Settings: map[no-autoupdate:true protocol:quic] 2022-12-08T07:48:41Z INF Environmental variables map[TUNNEL_TOKEN:*****] 2022-12-08T07:48:41Z INF Generated Connector ID: db308fe9-1425-4d70-80c8-f8caa3f92282 2022-12-08T07:48:41Z INF Initial protocol quic 2022-12-08T07:48:41Z INF ICMP proxy will use 172.18.0.16 as source for IPv4 2022-12-08T07:48:41Z INF ICMP proxy will use :: as source for IPv6 2022-12-08T07:48:41Z INF Starting metrics server on 127.0.0.1:41831/metrics 2022/12/08 08:48:41 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details. 2022-12-08T07:48:42Z INF Connection ec79f923-6b1b-4e3b-824c-4f732dab7877 registered with protocol: quic connIndex=0 ip=198.41.200.233 location=DUB 2022-12-08T07:48:43Z INF Connection 9ee7e168-f5c1-4c1f-9265-d7c7070b75df registered with protocol: quic connIndex=1 ip=198.41.192.167 location=MUC 2022-12-08T07:48:43Z INF Connection 12d75388-5373-4bb1-9672-de58a6d84b0f registered with protocol: quic connIndex=2 ip=198.41.200.23 location=DUB 2022-12-08T07:48:45Z INF Connection 68d9765e-2baf-438f-85b8-f2bb921f78cf registered with protocol: quic connIndex=3 ip=198.41.192.27 location=MUC

Here are the contents of my docker-compose.yml (token redacted to XXX):
`

version: “3.2”

services:
cloudflared:
image: Cloudflare/cloudflared
container_name: cloudflared
restart: unless-stopped
environment:
- TZ=Europe/Berlin
- TUNNEL_TOKEN=XXX
command:
- tunnel --config /home/nonroot/.cloudflared/config.yml run --token XXX
entrypoint:
- cloudflared
- --no-autoupdate
volumes:
- /mnt/user/appdata/cloudflared:/home/nonroot

networks:
default:
external:
name: bridge-net
`

I tried omitting the environment variable and I also tried omitting the --token switch. Both did not change anything in the behavior. Runnig the same using docker run --network bridge-net cloudflare/cloudflared:latest tunnel --no-autoupdate run --token XXX works fine out of the box.
What could I be missing here?

I think you are making it more complicated then it needs to be. Try something like

`

version: “3.2”

services:
    cloudflared:
        image: cloudflare/cloudflared:latest
        container_name: cloudflared
        restart: unless-stopped
        command: tunnel run
        environment:
           - TZ=Europe/Berlin
           - TUNNEL_TOKEN=XXX

networks:
    default:
    external:
       name: bridge-net

This is assuming that you are using a remote managed tunnel (created with the dashboard).

Yes, I’m using a remote managed tunnel.

I was down to defining image, container_name, restart, command, environment only in the docker-compose.yml, but still it started an accountless tunnel.
I diffed the output of docker inspect of the working container started using docker run and the not working one started via docker-compose up. command was the issue :frowning:

Here is the working part of the compose file:

  cloudflared:
    image: cloudflare/cloudflared
    container_name: cloudflared
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
      - TUNNEL_TOKEN=XXX
    command:
      - tunnel
      - run