Deployment Lifecycle

A Satusky deployment has more than one readiness dimension:

• build readiness — is there an image to run?
• workload readiness — are pods scheduled and healthy?
• endpoint readiness — is the public hostname routed, resolvable, and serving valid HTTPS?

Collapsing those into one green check hides the most common failure modes.

Current lifecycle

1ctl deploy
  │
  ├─ 1. read satusky.toml / flags
  ├─ 2. build image in-cluster with Kaniko, unless --image is supplied
  ├─ 3. upsert desired deployment state
  ├─ 4. reconcile Deployment + ConfigMap + Service + route
  ├─ 5. wait for pod readiness
  └─ 6. DNS / TLS continue converging for public access

Phase 1 — Resolve desired state

The CLI reads config and flags, resolves the organization namespace, and determines whether the deployment is new or an update. Flags override config values.

Template-backed deployments should eventually enter the same flow after template resolution. Marketplace should stop being operationally special once it has produced a normal workload spec.

Phase 2 — Build or reuse image

If no image is supplied, the CLI uploads a build context and the backend schedules Kaniko in-cluster. If an image is supplied, build is skipped and deployment reconciliation can begin immediately.

Phase 3 — Upsert deployment

The backend stores desired deployment metadata and then reconciles Kubernetes resources. Successful deploys create version snapshots used by rollback.

Phase 4 — Reconcile Kubernetes workload resources

Typical resources include:

• Deployment
• ConfigMap
• Service
• optional HPA / VPA / PDB
• optional PVC
• a public route primitive

Current route behavior

Hostname class	Current primitive
generated platform hostname	HTTPRoute in Gateway mode
custom domain / alias / redirect	legacy Ingress

The target is Gateway API everywhere, but that is not fully true today.

Phase 5 — Workload readiness

Kubernetes schedules pods, starts containers, and evaluates readiness probes. deployment_status: completed means the workload itself is ready; it does not prove the public URL works.

Phase 6 — Endpoint readiness

Public access requires four things to agree:

Plane	Question
Backend metadata	Which hostname should exist?
Route state	Does Kubernetes route that host to the Service?
DNS	Does the hostname resolve to the edge?
TLS / HTTP	Does HTTPS work and return the expected response?

Workload ready ≠ public endpoint ready

This is why future deploy output should report endpoint readiness separately rather than printing a single success state too early.

Reconciliation invariant

The backend, route resource, DNS record, and CLI output must converge on the same hostname. If the database reports one domain while the route still serves another, the control plane has drifted.

Release history and rollback

deployment_versions snapshots preserve successful deployment specs. Rollback is a new reconciliation using an older snapshot rather than a magical reversal of Kubernetes history.

Real-time status

The backend exposes WebSocket streams for live deployment status. Those are appropriate for build logs and pod rollout progress. Endpoint diagnostics need richer future reporting across route, DNS, TLS, and HTTP probes.

Current gaps and target direction

Gap	Target
Marketplace deploys still enter through a separate orchestration path.	Template resolution feeds this shared lifecycle.
Route readiness and workload readiness are easy to confuse.	Report them separately everywhere.
Custom domains still use a different routing primitive.	One Gateway API route model.
Public URL correctness can drift from stored metadata.	Reconciliation checks become first-class, not incidental.