Containerized apps

Docker and Kubernetes apps publish on Ntersection like anything else — and often more cleanly, because of one property worth understanding:

The agent publishes anything on its own network. Run the Ntersection agent as a container inside your compose network or cluster, and it can reach your services by name — http://myapp:8080, http://api.prod.svc.cluster.local:80. No host ports, no ingress controller, no load balancer. The tunnel dials out; nothing dials in.

Option 1 — simplest: you already publish a port

If your container runs with -p 8080:80 (or compose ports:), it’s just an app on localhost:8080. Use any normal publish path — the one-line agent install from My Machines, or the SSH command — with upstream http://127.0.0.1:8080. Done; nothing container-specific.

Option 2 — docker-compose: the agent as a sidecar

Add one service to your docker-compose.yml and drop the published port entirely. Get the ready-to-paste block (with your one-time link token filled in) from Portal → My Machines → Link a machine — it looks like this:

services:
  myapp:
    image: your/app        # no ports: needed!
  ntersection-agent:
    image: debian:stable-slim
    restart: unless-stopped
    volumes: [ "ntersection-identity:/data" ]
    command: [bash, -c, "<bootstrap: download agent, enroll once, run>"]
volumes:
  ntersection-identity: {}

Identity lives in the volume — the one-time token is consumed on first start only; restarts and image updates keep the same machine identity.
Publish with upstream http://myapp:8080 (the compose service name) in the portal’s publish form.
One agent can publish several services on the same network — one sidecar per stack, not per app.

Option 3 — Kubernetes: an in-cluster agent

Same idea at cluster scale: a one-replica Deployment (identity on a small PVC, Recreate strategy — one identity, one tunnel) that reaches every Service by cluster DNS. The manifest with your token filled in is also in My Machines:

PersistentVolumeClaim  ntersection-identity   (16Mi)
Deployment             ntersection-agent      (replicas: 1, strategy: Recreate)
  image: debian:stable-slim
  args:  <bootstrap: download agent, enroll once, run>
  volumeMounts: /data  → the PVC

Publish with upstream http://<service>.<namespace>.svc.cluster.local:<port>.
No Ingress, no LoadBalancer, no cert-manager — TLS, domains and identity come from the platform.
RBAC note: the agent needs no Kubernetes API access at all — it’s just a pod that makes outbound HTTPS/WSS.

Notes & honesty

The bootstrap downloads the agent at container start (no registry image to trust; you can pin by reading the script you paste). A prebuilt image may come later.
Agents are apps-only nodes by default — linking a machine never adds it to the GPU inference fleet.
Ephemeral caveat: if you skip the volume/PVC, a restart burns the identity and the agent can’t reconnect (tokens are single-use). Keep the volume.

→ Portal · My Machines to mint a token and get your filled-in snippets.