vela 0.11.3 → 0.11.5

package/README.md

@@ -45,6 +45,15 @@ vela provision root@your-server                        # Caddy, Node, PocketBase
 vela deploy --server root@your-server --domain example.com
 ```
 
+Any SvelteKit project deploys this way, PocketBase or not — `npx sv create my-app`
+straight into `vela deploy` works. The deploy looks at the project rather than at a
+config: a server needs `@sveltejs/adapter-node`, so a project still on `adapter-auto`
+(what `sv create` gives you) is switched to it on the first deploy, the package
+installed, and you are asked to commit the change. A project on `adapter-static` or a
+hosting platform's adapter is left alone and told why. Nothing on the server assumes a
+database: run `vela bless` whenever you want one and deploy again, and the same instance
+gains its PocketBase.
+
 That first deploy binds `production` to the server, so nothing after it names a
 machine again. Every command takes the same selector — `-t local`, `-t production`
 (or `prod`), or any name you choose such as `-t staging`:
@@ -55,7 +64,9 @@ vela env import .env.production -t production
 vela admin create -t production    # a login for the admin panel
 ```
 
-Each deploy uploads an immutable release, runs migrations, restarts the app and health-checks it. A release that does not come up healthy is rolled back before the command exits.
+Each deploy uploads an immutable release, runs migrations, restarts the app and health-checks it. A release that does not come up healthy is rolled back before the command exits, migrations included.
+
+One deploy runs per target at a time. A second one started from another machine — CI and a laptop, say — waits for the first to finish (up to `--lock-wait` seconds, 300 by default; `0` gives up at once), and a release that is older than the one already live is dropped rather than put back in front of it. Release ids are stamped from the server's clock so every machine agrees on which is newer.
 
 If any of your pages prerender from data, add `--remote-db` so the build renders against the database it is being deployed to, over the same SSH connection. Without it, a build on a fresh machine renders those pages against an empty database and bakes the defaults into your static HTML.
 
@@ -65,6 +76,8 @@ vela logs -f         # journald, tailed
 vela rollback        # previous release, with its down migrations
 ```
 
+`vela destroy deployment -t staging` removes a copy from its server. Its database and uploads stay behind unless you pass `--purge`, which snapshots them into `/var/lib/vela/trash` on the server (kept two weeks) before deleting. Removing production, or purging anything but a preview, asks you to type the app's name; from a script, pass `--confirm <app-name>` — `--yes` alone is not accepted for either.
+
 These default to `production`; `vela env` and `vela admin` default to `local`,
 because that is the copy you are usually standing in.
 
@@ -76,7 +89,9 @@ Same thing from CI with [`velastack/action`](https://github.com/velastack/action
 vela bless
 ```
 
-Adds the backend and the rest of the setup to a vanilla SvelteKit project, in place.
+Adds the backend and the rest of the setup to a vanilla SvelteKit project, in place. A
+project that is already deployed keeps deploying to the same instance, now with a
+database.
 
 ## It stays your code