Cana Desktop
Publish and deploy
Publish a project to your own Git repository with a build pipeline, add deployments to your Kubernetes clusters, and fix what breaks from the logs, all inside Cana Desktop.
How it works
The idea in 4 steps
- 1
Your code goes to your own repository
Publishing commits your project and pushes it to a new repository on your own GitLab, GitHub or Bitbucket, private unless you choose public. Nothing is hosted in a format only Cana can read.
- 2
A pipeline shows build and deployments
Each published app appears as a pipeline: a build, then one stage per deployment with its cluster and environment. When a build fails, one click hands the failure to the agent to fix.
- 3
Clusters connect with your own sign-in
Cana connects to your Kubernetes clusters, including Amazon EKS, using your own AWS profile or single sign-on. The agent can never read cloud credential folders such as ~/.aws or ~/.kube.
- 4
Look freely, change with approval
You and the agent can read resources, logs and YAML at any time. Changes such as apply, scale, restart or delete wait for your approval, so the agent can diagnose a crash without being able to break production on its own.
Tutorial
Step by step
Before you start
- Cana Desktop installed and signed in
- A Kubernetes cluster you can reach, for example on Amazon EKS
- kubectl installed, plus the AWS CLI and an AWS profile for EKS
- 1
Open Kubernetes
In Cana Desktop, click More tools on the left rail and choose Kubernetes.
You'll see: The Kubernetes view opens with your list of clusters, empty the first time.
Tip: Not listed? Open Mods, go to Marketplace and add it from the Cana tools type.
- 2
Start a connection
Press Connect cluster.
You'll see: The Connect Kubernetes Cluster dialog opens.
- 3
Sign in to AWS
Set Provider to Amazon EKS, choose your AWS Profile and Region, then press Authenticate & scan. Use Log in via SSO if your profile uses single sign-on.
You'll see: Cana signs in with your profile and lists the EKS clusters in that region.
Tip: If your account needs it, enter the code from your authenticator in MFA Code first.
- 4
Pick and verify the cluster
Choose your cluster under EKS Cluster and press Connect & verify.
You'll see: The cluster appears in the list and its namespaces, workloads and pods load.
- 5
Read a failing pod
Open a pod that keeps restarting and select its Logs tab.
You'll see: The pod's log streams live, so you can see the error that makes it crash.
- 6
Ask the agent
In the chat, ask "Why does this pod keep restarting? Read its logs and describe it, then propose a fix."
You'll see: The agent reads the logs and the resource, explains the cause and shows the change it proposes.
- 7
Approve or make the change
Approve the agent's change when it asks, or edit the resource yourself on its YAML tab and save it with Apply changes.
You'll see: The change is applied to the cluster and new pods start.
Tip: Use Restart to roll pods, or Scale and set Replicas to change how many run.
Worked example
Fix a crashing checkout service
Your checkout service on staging keeps restarting after a release and customers see errors. You want the cause and a fix without hunting through logs by hand.
You type
The checkout pod in staging keeps restarting. Read its logs and events, tell me why, and propose the smallest fix.
- 1.Open Kubernetes and connect your EKS cluster
- 2.Open the checkout pod and its Logs tab
- 3.Send the prompt in the chat
Result: The agent finds a missing environment variable in the logs, proposes the Deployment change and applies it after you approve. The new pods stay running.
Troubleshooting
If something doesn't work
- Kubernetes is not in More tools
- It is a Cana tool you add once. Open Mods, then Marketplace, set the type filter to Cana tools and add Kubernetes.
- Authenticate & scan finds no clusters
- Check the Region is the one your cluster runs in and that the AWS profile can list EKS clusters there.
- My SSO session expired
- Open Connect cluster again and use Log in via SSO, then Connect & verify.
- The agent did not change the cluster
- Cluster changes wait for your approval, and they are refused in Research and Plan mode. Switch the permission mode and approve the change when asked.
For you
Ship faster on your own infrastructure, with approval on every change
Code is published to your organisation's own Git host and runs on your own clusters, using your own cloud sign-in. The agent can read and diagnose freely, but changes to a cluster need explicit approval, and cloud credentials are off-limits to it.
Ownership
Repositories, pipelines and clusters remain yours; Cana works with them rather than hosting them.
Reduced downtime
Failing workloads are diagnosed from their logs in minutes, with the proposed fix shown before it is applied.
Guarded production
Manual sync options and approval-gated cluster actions keep production changes deliberate.
What changes for leaders: Shorter path from build to production on infrastructure you own, without loosening change control.
Technical details
What it connects to, and the controls you have
- Repositories
- Publishes to GitLab, GitHub or Bitbucket through a repository connection; new repositories are private by default
- Pipeline view
- Build stage plus one stage per deployment, each labelled with its environment and cluster
- Deployment options
- Auto or manual sync, automatic or manual pipeline trigger, optional ingress domain
- Clusters
- Kubernetes clusters, including Amazon EKS with your own AWS profile, SSO and MFA; opened from Kubernetes under More tools on the left rail
- Cluster actions
- Browse resources, live pod logs, edit and apply YAML, restart and scale workloads, kubectl terminal
- Agent controls
- Read-only kubectl actions (get, describe, logs, top) run freely; apply, delete, exec, scale and rollout ask for approval and are refused in Research and Plan mode
- Credentials
- Cloud credential folders such as ~/.aws and ~/.kube are protected paths the agent can never read
Why Cana
What you get here
- Publish to your own Git repository, private by default, from inside the app
- Build and deployment pipeline shown per app, with Fix with AI on failures
- A full Kubernetes view with logs, YAML apply, restart, scale and a kubectl terminal
- Agent cluster changes need approval; read-only checks run without interrupting you
Keep exploring
Build an app from one prompt
Faster software delivery, with human approval and verified results
Code, terminal and approvals
AI that works on your code without access to your secrets
Permissions and approvals
Human approval by default, and hard limits no setting can override
Automations
Routine work automated, with approval up front and limits built in