Kubernetes
Cmdop publishes no Kubernetes manifests, and running it on a cluster is not the
intended shape. The relay is one binary on one host, and the machines it operates
are real computers that dial out to it — neither is a workload a scheduler
places. If you run the relay as a pod anyway, cmdop server has the flags a
headless deployment needs.
Cmdop does not publish Kubernetes manifests. The relay is a single binary on a host, and the machines you operate are real computers that dial into it — neither is a workload a cluster schedules for you.
To run a relay, install the binary on a host and create one:
cmdop server create --mode public --subdomain my-box --no-prompt
cmdop server --detachSee Self-hosted relay.
If you run it as a pod anyway
cmdop server takes the flags a headless deployment needs:
--initial-admin-password-file seeds the first admin password from a mounted
secret and is ignored after initialization, --no-banner keeps the join key
out of pod logs, and --no-open stops it from trying to launch a
browser. Publish HTTP 63141 and gRPC 63142 for LAN mode; public and
own-domain modes terminate TLS at the relay’s own door.
Manifests published here previously deployed an earlier Python relay architecture. They do not apply to the current binary.
Common questions
Does Cmdop publish Kubernetes manifests?
No. Cmdop does not publish Kubernetes manifests for the current relay. The
intended deployment shape is one cmdop binary on one host, with real machines
dialing into that relay.
Can I run the relay in a Kubernetes pod anyway?
You can, but treat it as running the binary in a headless process, not as a native clustered workload. Use the headless flags, keep secrets out of logs, and publish the relay ports that match the mode you chose.
Are the machines I operate Kubernetes workloads?
No. Cmdop operates joined computers. Those machines may be servers that also run workloads, but fleet membership and agent reachability are not scheduled by Kubernetes.
Cmdop