tinycloud-link/docker-compose.phala.yml at main · TinyCloudLabs/tinycloud-link · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
services:
  # Public HTTPS ingress for the control-plane API's own hostname
  # (api.tinycloud.link) ONLY. dstack-ingress is an HAProxy-based L4 (TCP)
  # proxy: it terminates TLS with its own ACME DNS-01 flow and forwards the
  # decrypted stream to TARGET_ENDPOINT untouched, Host header and all --
  # there is no per-SNI certificate hook from inside this CVM (see README.md
  # "Ingress and TLS for tunnels").
  #
  # DOMAIN is single-hostname, not wildcard: dstack#545 staging verification
  # found the gateway does not route wildcard SNI on this dstack generation
  # (ACME wildcard cert issuance succeeded, but the gateway silently reset
  # every TLS handshake for a wildcard hostname -- see the TC-85 Linear
  # comment for the full repro). Per the resulting decision, *.tinycloud.link
  # (every tunnel name, TC-85's remote-reachability namespace) is instead
  # fronted by a Cloudflare Worker (worker/, README's "Cloudflare Worker
  # front" section): Cloudflare terminates TLS for the wildcard at its own
  # edge and forwards to this same api.tinycloud.link hostname, carrying the
  # tunnel name in X-Forwarded-Host. dstack-ingress and this process are
  # unaware anything changed -- they still only ever see api.tinycloud.link.
  dstack-ingress:
    image: dstacktee/dstack-ingress:20250924@sha256:40429d78060ef3066b5f93676bf3ba7c2e9ac47d4648440febfdda558aed4b32
    ports:
      - "443:443"
    environment:
      - DOMAIN=api.tinycloud.link
      - TARGET_ENDPOINT=http://tinycloud-link:3000
      - CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
      - GATEWAY_DOMAIN=_.${DSTACK_GATEWAY_DOMAIN}
      - CERTBOT_EMAIL=${CERTBOT_EMAIL}
      - SET_CAA=true
    volumes:
      - /var/run/dstack.sock:/var/run/dstack.sock
      - tinycloud-link-cert-data:/etc/letsencrypt
    restart: unless-stopped

  tinycloud-link:
    image: ghcr.io/tinycloudlabs/tinycloud-link:main
    environment:
      - PORT=3000
      - DATABASE_URL=postgres://tinycloud_link:${POSTGRES_PASSWORD}@postgres:5432/tinycloud_link
      - CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
      - CLOUDFLARE_ZONE_ID=${CLOUDFLARE_ZONE_ID}
      - ACME_EMAIL=${ACME_EMAIL}
      - ACME_DIRECTORY=${ACME_DIRECTORY:-https://acme-staging-v02.api.letsencrypt.org/directory}
      - ATTESTATION_DOCUMENT=${ATTESTATION_DOCUMENT:-}
      - API_HOSTNAME=${API_HOSTNAME:-api.tinycloud.link}
      # Shared secret with the Cloudflare Worker front -- see README's
      # "Cloudflare Worker front" section. Tunnel routing itself (the
      # TunnelRegistry, src/tunnel/host-router.ts) has no separate on/off
      # env var: it's unconditionally wired up in src/index.ts by every
      # build of this image since TC-85 merged. This secret only gates
      # whether X-Forwarded-Host is trusted for routing by tunnel name.
      - TUNNEL_FRONT_SECRET=${TUNNEL_FRONT_SECRET}
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped

  postgres:
    image: postgres:17-alpine
    environment:
      - POSTGRES_DB=tinycloud_link
      - POSTGRES_USER=tinycloud_link
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - tinycloud-link-postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U tinycloud_link -d tinycloud_link"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  tinycloud-link-cert-data:
  tinycloud-link-postgres-data: