Skip to main content
Version: 1.0

Basic Operations

This walks through the operations you'll actually use day to day as a tenant: deploying an app, checking on it, and changing it once it's running. There's no separate CLI for any of this — every operation described here goes through the dashboard, which in turn talks to KubeOpera API on your behalf.

Deploying your first app​

From your CloudSpace, the Deploy Application Wizard is where every app starts. It supports two sources: an existing container image in a registry (public or private), or a GitHub repository, which triggers a real Kaniko build from your Dockerfile before deploying the resulting image — the wizard's own progress view walks through Creating, Syncing, Starting, and finally Verifying reachability, and only shows your app's live link once that last check — a genuine outbound HTTPS request against the app's own computed subdomain — actually succeeds. That subdomain, <app>-<cloudspace-slug>.apps.kubeopera.io, is computed for you; there's nothing to configure DNS-wise on your end.

Behind that progress view, your app's desired state is written to Git and a controller reconciles it into your CloudSpace's own vCluster — not the shared host cluster — which is also why deleting an app later genuinely tears down everything it created rather than just removing a database record.

Checking on a running app​

The Workloads view under your CloudSpace lists every app you've deployed, along with real-time status derived from the actual Kubernetes state, not a cached value. Opening a specific app gives you its pods, recent events, and logs, all scoped to your own vCluster — you're never looking at another tenant's namespace by accident, and there's nothing to configure to make that isolation work.

Changing a running app​

Restart, scale, and stop/start apply directly to your app rather than going through the same Git-and-reconcile path a fresh deploy uses — this is deliberate, so these feel instant rather than waiting on a reconcile interval. Configuration changes (a new image, a different port, updated environment variables, resource limits) do go through the normal Git-backed path, the same one the initial deploy used.

Every meaningful configuration change creates a Deployment revision, visible in your app's Deployment History — this is read directly from Kubernetes' own record of what changed, not a separate log KubeOpera maintains, so it can never drift out of sync with reality. If a change causes a problem, rolling back to a prior revision from that same view reverts your app's configuration to exactly what it was at that point, through the same Git-backed path a normal edit uses — a rollback is really just a configuration edit whose new values happen to come from history.

Next Steps​