vela 0.10.2 → 0.10.4

package/README.md

@@ -31,6 +31,40 @@ vela ui add button card dialog                       # components, into your pro
 
 Changed your mind? `vela destroy` and `vela disable` take it back out.
 
+## Ship it
+
+Deploys go to a server you own, over SSH. Prepare the box once, then deploy as often as you like.
+
+```sh
+vela provision root@your-server                        # Caddy, Node, PocketBase, systemd, TLS
+vela deploy --server root@your-server --domain example.com
+```
+
+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`:
+
+```sh
+vela targets                       # what exists, and where
+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.
+
+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.
+
+```sh
+vela status          # what is running, on which release
+vela logs -f         # journald, tailed
+vela rollback        # previous release, with its down migrations
+```
+
+These default to `production`; `vela env` and `vela admin` default to `local`,
+because that is the copy you are usually standing in.
+
+Same thing from CI with [`velastack/action`](https://github.com/velastack/action).
+
 ## Already have a project?
 
 ```sh