Your cluster

Every account comes with its own Kubernetes control plane over an isolated space. This page is about what that means in practice — what you can reach with kubectl, where your code lives, and what the platform still does for you.

Last updated 2026-09-05

What "your own cluster" means here

There are two levels, and the dashboard tells you which one you are on.

Shared (the default, Free and Pro). Your apps run in a Kubernetes namespace that is yours alone on the platform's cluster. You get a kubeconfig scoped to that namespace with edit rights: list, inspect and log pods, scale and restart deployments, apply your own manifests — and provably no access to other tenants, to cluster nodes, or to anything that could escalate. Validated in isolation before it shipped.
Dedicated (Pro). A fully separate k3s cluster with its own API server and its own nodes, reachable over your Tailscale private link. Nothing is shared with anyone. This is the level your own devices join as full nodes (see Nodes), and the one where kubectl get nodes shows machines you plugged in yourself.

Both are standard Kubernetes reached with a standard kubeconfig — not a proprietary box with a Kubernetes-shaped API.

Download the kubeconfig

Open the Cluster tab on your dashboard.
Expand "Advanced · manage it yourself with kubectl". It sits under the "Your cluster is live" step.
Click Download kubeconfig. You get my-app.kubeconfig. Keep it private — it is your credential.

$ export KUBECONFIG=~/Downloads/my-app.kubeconfig
$ kubectl get deploy,svc,pvc
$ kubectl logs deploy/<your-app> -f
$ kubectl scale deploy/<your-app> --replicas=2

Inside your space, anything kubectl can do you can do: scale a deployment, read logs, port-forward to a database, apply your own manifests. Helm works too — it only needs the kubeconfig. On a dedicated cluster the same file also gives you the cluster-wide view (kubectl get nodes).

With power comes the usual caveat: if you delete the deployment the agents created, the app is down until you or the agents recreate it. The platform does not silently undo what you do with kubectl.

What lives in your namespace

Your apps — one Deployment and Service per app, with an Ingress that answers on <app>.<your-username>.my-app.engineer and on any custom domain you connect.
Databases — when an app needs one, the agents add a Postgres in your namespace with a persistent volume. It is yours to psql into through a port-forward.
Tools you install — each cluster tool runs in your space, on its own secure address that only you can reach.
Secrets — API keys you give an app are stored as Kubernetes Secrets in your namespace. Per-user platform secrets are kept encrypted at rest (see the privacy policy).

Where your code lives

Every app is a private git repository at gitlab.my-app.engineer/tenants/<your-username>/<app>. The agents commit there as they build; you can clone it, read it, and push to it. The workspace where the agents work — the files you see in the in-browser IDE — is stored on encrypted block storage and mirrored to that repo.

Leaving, or taking it with you

Your code is in standard git repos. Your app is standard Kubernetes manifests in a namespace you can read with kubectl. Your database is a normal Postgres you can dump with the tools you already know. There is no proprietary format between you and your own work. Account records are exportable as JSON at GET /api/me/export while logged in, and Delete cluster on the dashboard erases the whole tenancy.

← Getting started Nodes: yours or rented →