deploy-flyte-kind-vm: document console + tunnel-free SDK access from a cloud VM (DigitalOcean), run-URL host mismatch, and -N/doctl pitfalls

[cosmicBboy]

Summary

Follow-up to #18, this time for the deploy-flyte-kind-vm skill (the cloud-VM variant). I deployed Flyte-on-kind to a DigitalOcean droplet and it worked end-to-end (test runs completed all task pods against Supabase + R2), but a few VM-specific things were rough or undocumented — mostly around browser/SDK access from the user's machine to the VM. The storage config gaps from #18 also apply here since this skill hands off to deploy-flyte-kind.

Setup: droplet s-4vcpu-8gb / nyc1, Ubuntu 24.04, kind + flyte-binary v2.0.27, Supabase (session pooler) + Cloudflare R2, flyte SDK 2.5.8.

---

VM-specific issues / gaps

1. Browser console on a VM isn't covered by the base (no-auth) path

The base deploy installs no ingress controller, so the console is unreachable the same way as #18 — but on a VM you can't just kubectl port-forward the console and browse localhost. What works cleanly:

• Install Traefik (the skill only does this in the optional auth section) with service.type=NodePort, ports.web.nodePort=30080, ports.websecure.nodePort=30443 — matching the kind host-port mappings the skill already creates (30080→80, 30443→443).
• Add two IngressRoutes for a unified origin (the console frontend calls the API same-origin — see flyte-deploy-kind: local kind + R2 deploy needs task-pod storage creds, runs.storagePrefix override, and console-origin fix #18): PathPrefix('/flyteidl2.') → flyte-http:8090 (scheme h2c), and / → flyte-console:80.
• Because kind maps the droplet's host port 80 → Traefik, the console is then reachable directly at http://<droplet-ip>/v2 (firewall already scoped to your IP) — no tunnel at all. Or tunnel it: ssh -N -L 8080:localhost:80 root@<ip>.

Suggest adding a short "Access the console from a VM (no auth)" recipe covering the Traefik install + the two routes + direct public-IP access.

2. SDK can be tunnel-free too — the skill only shows the SSH tunnel

Step 4 documents the SDK access as an SSH tunnel + kubectl port-forward only. Once Traefik is routing /flyteidl2.* (item 1), the SDK can point straight at the VM's public IP and drop the tunnel entirely:

# .flyte/config.yaml
admin:
  endpoint: dns:///<droplet-ip>:80
  insecure: true

gRPC rides Traefik's web entrypoint over h2c on port 80 and works (verified a full run with every SSH tunnel stopped). Worth mentioning as the lower-friction option for evaluation, with the caveat that it's plain HTTP over the public internet (firewall-scoped to your IP).

3. Run URLs are advertised as localhost:8080 regardless of host

flyte run prints URL: http://localhost:8080/v2/... even when deploying to a VM. On a VM those links are dead — the user has to manually swap the host to <droplet-ip>. Would be good to (a) note this in the skill, and/or (b) file upstream to make the console base URL configurable so VM deploys advertise the right host.

4. -N pitfall on the SDK tunnel

The Step 4 tunnel that runs a remote command —
ssh -L 8090:localhost:8090 root@<ip> kubectl -n flyte port-forward ... — must not include -N: -N tells SSH not to execute the remote command, so kubectl port-forward never starts and the forward gets connection refused. The skill's example is correct (no -N), but a one-line warning would save people who add it out of habit. (Conversely, the pure console tunnel in item 1 does want -N since there's no remote command.)

5. doctl prerequisite / non-interactive auth

Minor: the skill assumes doctl is installed and authenticated. Worth noting brew install doctl and that auth can be done non-interactively with doctl auth init -t <token> (handy when a token is pasted rather than entered at the prompt). Also that the SSH key must be imported to DO first (doctl compute ssh-key import <name> --public-key-file ~/.ssh/id_ed25519.pub) and its ID passed to droplet create.

---

Suggested skill improvements

1. Add a "Console + SDK access from a VM" section: Traefik install + the two unified-origin IngressRoutes, then both (a) direct public-IP access http://<ip>/v2 and (b) tunnel-free SDK endpoint: dns:///<ip>:80.
2. Note the localhost:8080 run-URL host mismatch on VMs (and consider an upstream ask to make the console base URL configurable).
3. One-line -N warning on the SDK tunnel command.
4. Brief doctl setup notes (install, -t token auth, ssh-key import).
5. Cross-reference flyte-deploy-kind: local kind + R2 deploy needs task-pod storage creds, runs.storagePrefix override, and console-origin fix #18 so VM users apply the task-pod FLYTE_AWS_* env vars and runs.storagePrefix override (required for tasks to run).

Happy to send a PR bundling #18 + this into the two skill docs.

Teardown was clean: doctl compute droplet delete flyte-kind + firewall + ssh-key; Supabase/R2 untouched.