A desktop client for Kubernetes
Timoneer
Work with your Kubernetes clusters from one window that starts from what is broken, keeps the cluster you are working on in view, and confirms every change by naming the object and the cluster.
Who it is for
For engineers who work with Kubernetes clusters day to day - including clusters that are somebody else's production, and credentials that are only allowed to read.
What it does
Every cluster in your kubeconfig
Timoneer reads the contexts in your kubeconfig. Switching to another cluster stops the process that worked with the previous one and starts a new one, and the name of the current cluster is always on screen.
Start from what is broken
Opening a cluster lands on an overview of objects in an abnormal state, such as pods in CrashLoopBackOff, instead of a list of namespaces. When a count is not known, the overview says so instead of showing zero.
One place for an object
The object panel shows its owner, its events, its logs and the status of its containers. Logs, the terminal and events open as tabs in one dock.
Logs and a terminal at the level of kubectl
Follow and filter logs and read the previous container's logs; exec and attach into containers; forward ports - implemented in the application, without running kubectl.
Any resource, including custom resources
The list of resource types is built from the cluster's discovery API, not from a list written into the application.
Honest on narrow permissions
Timoneer is fully usable with get, list and watch. An action your credentials will not be allowed stays where it is and says why, instead of being greyed out.
Changes are confirmed
Every change to a cluster is confirmed in one window that names the object and the cluster, and deleting asks you to type the name. In the YAML editor, what you see is what is compared and what is sent, and the server checks it with a dry run first.
Zero telemetry
Zero telemetry. This application does not collect or send data about you or your clusters. It connects only to the Kubernetes API servers named in your kubeconfig — directly, or through a proxy server if your kubeconfig names one. It does not connect to any server of ours.
A credential program from your kubeconfig. Your kubeconfig can name a program that issues credentials for a cluster, for example aws, kubelogin or gke-gcloud-auth-plugin. This application runs such a program only after you consent, in a window that shows which program will run and with which arguments. The program connects wherever it connects — usually to your cloud's sign-in service — and it may open your browser. That is the program's traffic, not ours: we do not read it, we do not relay it and we do not pass it on anywhere. From the program we take only the credential it prints, and we send it only to the API server of the same context.
What we do not do:
- we have no analytics SDK, no APM, no session replay and no “anonymous usage statistics” — not disabled, but absent from the code;
- we send no usage events, no heartbeats and no installation identifier — nowhere and in no header;
- we have no account, no sign-in with us, no online activation and no license checked over the network; if something asks you to sign in, it is the credential program asking you to sign in to your cloud;
- we have no update server and no remote configuration;
- we send no crash reports; crash dumps stay on your disk and leave this machine only if you send them yourself;
- we send cluster names, context names, namespace names, resource names and log contents nowhere except to your API servers;
- we load no fonts, workers, validation schemas, spell-check dictionaries or any other resources from the network — everything is in the artifact;
- we have no extensions; if they ever appear and have network access, we will rewrite this promise before the first such extension, not after.
Air-gapped: there is nothing to switch off — apart from the API servers in your kubeconfig and the credential program you consent to, this application connects to nothing. If we ever add an update check or any other connection to a server of ours, we will change this promise before the release in which it appears, not after.
What we do not promise, so as not to promise too much: we are not responsible for where the credential program connects or what it sends — it is your cloud provider's program or your own, run with your configuration. Your operating system may report crashes independently of us.
How to check this without taking our word for it: this application can be measured from the outside, without our cooperation — run it behind a recording proxy and see where it connects. Before every release we run such a measurement ourselves on the installed application, with the credential program's connections listed separately, and we attach its result, together with the SHA-256 of the measured artifact, to the release. To be honest about what this does not cover: the application's source code is closed, so claims about the code — for example that there are no analytics SDKs in it at all — are our commitment, which you cannot check from the outside. A measurement from the outside shows what the application does under the conditions you check; it cannot show that no condition exists that nobody has checked.
Free to use
Using Timoneer requires no account, no sign-in with us, no activation and no connection to a server of ours. The free track carries no fee; it covers every individual using it outside an organisation's activity and, until the Sales Opening Day, every organisation.
Download
No installer has been released yet.
The first public release will be an Alpha for Windows. A Linux build, as a single unsigned .deb file whose SHA-256 digest is published on this site, follows only after its security checks have been measured on a real Ubuntu system; there is no date for it yet. Release 1.0 declares Windows only.
Before any file can be downloaded, this site publishes the licence it carries, the SHA-256 digest of each installer file and the source code of the FFmpeg library inside it.