Store deployment configs locally for binary deployments

For binary and static deployments, .ship/service and .ship/Caddyfile are
now written to the local working directory (similar to git deployments)
instead of being regenerated on every deployment.

- On initial deployment, create local .ship/ directory with generated configs
- On subsequent deployments, upload from local .ship/ files
- Caddyfile is never regenerated, preserving custom routes
- Systemd service is regenerated only when --memory, --cpu, or --args change

This prevents custom Caddyfile routes from being overwritten and makes
binary deployment workflow consistent with git deployment workflow.

1 files changed, 6 insertions, 0 deletions

diff --git a/README.md b/README.md
index cdd4127..c440c49 100644
--- a/README.md
+++ b/README.md
@@ -70,6 +70,12 @@ GOOS=linux GOARCH=amd64 go build -o myapp
 ship --binary ./myapp --domain api.example.com
 ```
 
+On first deployment, Ship creates a `.ship/` directory in your current working directory containing:
+- `.ship/service` - systemd unit file
+- `.ship/Caddyfile` - Caddy reverse proxy config
+
+These files are uploaded on each deployment. You can edit them locally to customize your deployment (add extra Caddy routes, adjust systemd settings). The systemd service is regenerated when you update resource limits with `--memory`, `--cpu`, or `--args` flags. The Caddyfile is never regenerated, so your custom routes won't be overwritten.
+
 You can version control `.ship/` or add it to `.gitignore` — it's your choice.
 
 ## Commands