Commit

c75a2dc

replying to @dtinth
On it — doing SMB rewrite, dynamic 'Reaching the share', Desktop summary, dropping Selkies 'prototype', renaming the heading to Behavior, the border fix, and removing the AGENT_ENV_COMPONENTS chip. One clarify: image 1 ('UI Scaling'/'Command sends Control') isn't the configurator…
Selkies scaling fix done too: run-selkies now passes --scaling-dpi=96, which LOCKS it to 100% server-side (a single value means the client can't change it), so the phone no longer auto-picks 300%. Matches noVNC 1:1; DESKTOP_DPI still scales XFCE itself. Can't live-test without a…
Like it. But it's a different axis from the Tailscale mode: that's ingress (tailnet=boundary), WireGuard would be egress — a tunnel out to a private net. Needs NET_ADMIN + /dev/net/tun, so same 'host relaxes sandbox' tier as Docker. Use case — reaching internal services?
Ah, so it's ingress after all — a self-hosted tailnet. Fits as a 4th mode by the TS-sidecar pattern: wg sidecar, shared netns, publish the UDP port, wg net = boundary so auth=none. Cost vs Tailscale: no coordinator, you hand-manage keys+peers. Want me to spec it?
Grill Q1 (root): is WireGuard a new deployment MODE — mutually exclusive with local/domain/tailnet, i.e. it IS the boundary — or a component layered on another mode? My rec: a 4th mode. Like the tailnet it sets PUBLIC_URL, port layout, and auth=none default. Agree?
Hmm, not sure if we can modularize them like we did components. Like: + expose + port mappings + Caddy ingress + Tailscale + Wireguard what do you think
Blocker to free checkboxes: the network namespace. Tailscale & WireGuard each work by the app sharing the sidecar's netns — you can share only one. So the VPNs can't stack with each other, nor with host port-mappings. Only Caddy-vs-raw-expose is a cleanly separable layer, and…
Two axes, not N checkboxes. AXIS A — L3 reach (pick ONE; it owns the netns): - loopback: 127.0.0.1 only, bring your own proxy - published: host port mappings on 0.0.0.0 - tailscale: sidecar, tailnet = boundary - wireguard: sidecar, wg net = boundary…
Good catch — yes. Call it 'internal': no host ports, container exposed only on the compose network; Dokploy's Traefik (or any sibling proxy) joins that net and does ingress+TLS. It's distinct from loopback: loopback = a proxy on the HOST, internal = a proxy in a CONTAINER on the…
AXIS A — Title: 'How is it reached?' (pick one) Internal (behind an orchestrator) ✓ No host ports; exposed only on the compose network ✓ Dokploy/Traefik or a sibling proxy routes in and does TLS ⚠ Proxy is usually public — auth required by default → PUBLIC_URL is whatever the proxy serves Loopback (this machine only) ✓ Ports bind 127.0.0.1; reachable from the host only ✓ Put your own host proxy in front → auth=none is fine (you own the front) Published (open host ports) ✓ Ports bind 0.0.0.0, published on the host ⚠ Directly reachable on the public interface — auth required → choose TLS below (Axis B) Tailscale ✓ Sidecar joins your tailnet; tailnet = boundary ✓ SSH/mosh with nothing published; tailscale serve is the way in ✓ No host ports; auth=none OK → needs a TS auth key WireGuard ✓ wg sidecar; wg network = boundary ✓ VPS public IP + a published UDP port = dial-in endpoint ✓ Peers reach services on the wg address; auth=none OK ⚠ No coordinator — you hand-manage server key, port, each peer pubkey+IP → needs NET_ADMIN + /dev/net/tun AXIS B — Title: 'TLS & domain' (shown only when A=Published) Raw TCP ✓ Serves plain on the published port ⚠ No cert — fine behind your own TLS, not the open internet Caddy (public domain) ✓ Bundled Caddy gets a Let's Encrypt cert for your domain ✓ Publishes :80 (ACME) and :443 → needs a domain pointed here; auth required

commit c75a2dc