From 7de14beb6aeaceb06706b0acb20406b0d4f3fa63 Mon Sep 17 00:00:00 2001 From: David Boreham Date: Thu, 20 Aug 2026 09:21:37 -0600 Subject: [PATCH] Update recent features and skills --- docs/recent-features.md | 1 + skills/deploy-with-stack/SKILL.md | 15 ++++++++++----- 2 files changed, 11 insertions(+), 5 deletions(-) diff --git a/docs/recent-features.md b/docs/recent-features.md index 64067ec..844ff17 100644 --- a/docs/recent-features.md +++ b/docs/recent-features.md @@ -1,5 +1,6 @@ # Recent New Features + - [#292](https://github.com/bozemanpass/stack/pull/292) [`stack manage … destroy`](./commands/manage.md#destroy): the signal that a deployment is finished, so what it left in a cluster can be collected — `stop` and `start` are symmetric now and delete nothing permanent, while `destroy` takes the volumes, the namespace and (on kind) the cluster, keeping backups and any certificate a redeployment could still use - [#272](https://github.com/bozemanpass/stack/pull/272) [Sandboxed pods on Kubernetes](./k8s-deployment-enhancements.md): a spec's `runtime-class` puts named services on a RuntimeClass such as kata, so a service running untrusted code gets a VM of its own while the rest of the deployment stays ordinary containers - [#266](https://github.com/bozemanpass/stack/pull/266) [Stack integrity checking](./stack-integrity.md): `stack validate` verifies a stack's files agree with each other, and the same checks run advisorily during `prepare`, `build` and `init` - [#260](https://github.com/bozemanpass/stack/pull/260) `stack manage … update` converges a running deployment onto changed images and configuration, recreating only the services that changed diff --git a/skills/deploy-with-stack/SKILL.md b/skills/deploy-with-stack/SKILL.md index 4a23312..17c4b3c 100644 --- a/skills/deploy-with-stack/SKILL.md +++ b/skills/deploy-with-stack/SKILL.md @@ -23,7 +23,7 @@ then a fixed four-command pipeline takes it to a running system: stack build containers # build the images stack init # generate a deployment spec (choose target, ports, config) stack deploy # materialize a deployment directory from the spec -stack manage # start / stop / logs / exec against that directory +stack manage # start / stop / logs / exec / destroy against that directory ``` The same stack deploys unchanged to Docker Compose (`--deploy-to compose`), a real @@ -236,16 +236,21 @@ stack manage --dir ./myproject-deployment logs -f backend # follow one servi stack manage --dir ./myproject-deployment update # apply config/image changes ``` -To stop: `stack manage --dir ./myproject-deployment stop` (data volumes are preserved; -add `--delete-volumes` only if the user explicitly wants the data gone). +To stop: `stack manage --dir ./myproject-deployment stop`. Stop is the opposite of start +and nothing more — the data is still there when it starts again. When a deployment is +finished for good, `stack manage --dir ./myproject-deployment destroy` deletes its +volumes too (it asks first, and backups are kept). Only ever reach for `destroy` when +the user has said the deployment and its data are done with. ## Iterating After changing service source: rebuild (`stack build containers --stack ./stack`), then `update` the deployment — it recreates only the services whose image or configuration changed. After changing `stack.yml` or the composefile: rerun `init` and `deploy` to a -fresh deployment directory (or the same one after `stop`), since `update` applies content -changes only and refuses changes to the deployment's shape. +fresh deployment directory, since `update` applies content changes only and refuses +changes to the deployment's shape. `deploy` will not write into a directory that already +exists, so reusing a name means destroying the old deployment and removing its directory +first. ## Choosing where to deploy