dash 3.1.5 → 3.2.1

data/lib/{kamal → dash}/configuration/docs/accessory.yml

@@ -6,8 +6,8 @@
 # Accessories are managed separately from the main service — they are not updated
 # when you deploy, and they do not have zero-downtime deployments.
 #
-# Run `kamal accessory boot <accessory>` to boot an accessory.
-# See `kamal accessory --help` for more information.
+# Run `dash accessory boot <accessory>` to boot an accessory.
+# See `dash accessory --help` for more information.
 
 # Configuring accessories
 #
@@ -40,7 +40,7 @@ accessories:
     #   <<: *specific-registry
     # ```
     #
-    # See kamal docs registry for more information:
+    # See dash docs registry for more information:
     registry:
       ...
 
@@ -83,7 +83,7 @@ accessories:
 
     # Environment variables
     #
-    # See kamal docs env for more information:
+    # See dash docs env for more information:
     env:
       ...
 
@@ -157,10 +157,10 @@ accessories:
     #
     # You can run your accessory behind the Kamal proxy for hostname-based
     # routing and automatic SSL. The block accepts the same schema as the
-    # app-level `proxy:` (see `kamal docs proxy`), though root-only keys such as
+    # app-level `proxy:` (see `dash docs proxy`), though root-only keys such as
     # `loadbalancer` and `reboot_on_deploy` have no effect inside an accessory.
     # Declaring a proxy here makes the accessory's hosts proxy hosts:
-    # `kamal proxy boot` (and `kamal deploy`) will run kamal-proxy on them
+    # `dash proxy boot` (and `dash deploy`) will run kamal-proxy on them
     # automatically.
     #
     # Accessories are never load balanced. The loadbalancer fans the app's own

data/lib/{kamal → dash}/configuration/docs/alias.yml

@@ -5,7 +5,7 @@
 # For example, for a Rails app, you might open a console with:
 #
 # ```shell
-# kamal app exec -i --reuse "bin/rails console"
+# dash app exec -i --reuse "bin/rails console"
 # ```
 #
 # By defining an alias, like this:
@@ -14,7 +14,7 @@ aliases:
 # You can now open the console with:
 #
 # ```shell
-# kamal console
+# dash console
 # ```
 
 # Configuring aliases

data/lib/{kamal → dash}/configuration/docs/boot.yml

@@ -6,7 +6,7 @@
 #
 # This is a whole-deploy setting: `limit` slices the combined host list of every role, so it cannot
 # hold one role back while another keeps booting. To pace a single role's hosts, set `boot` on that
-# role instead (see kamal docs role).
+# role instead (see dash docs role).
 
 boot:
 

data/lib/{kamal → dash}/configuration/docs/builder.yml

@@ -19,13 +19,13 @@ builder:
 
   # Remote
   #
-  # The connection string for a remote builder. If supplied, Kamal will use this
+  # The connection string for a remote builder. If supplied, dash will use this
   # for builds that do not match the local architecture of the deployment host.
   remote: ssh://docker@docker-builder
 
   # Local
   #
-  # If set to false, Kamal will always use the remote builder even when building
+  # If set to false, dash will always use the remote builder even when building
   # the local architecture.
   #
   # Defaults to true:
@@ -87,7 +87,7 @@ builder:
 
   # Build secrets
   #
-  # Values are read from `.kamal/secrets`:
+  # Values are read from `.dash/secrets`:
   secrets:
     - SECRET1
     - SECRET2

data/lib/{kamal → dash}/configuration/docs/configuration.yml

@@ -5,7 +5,7 @@
 # Destinations
 #
 # When running commands, you can specify a destination with the `-d` flag,
-# e.g., `kamal deploy -d staging`.
+# e.g., `dash deploy -d staging`.
 #
 # In this case, the configuration will also be read from `config/deploy.staging.yml`
 # and merged with the base configuration.
@@ -44,19 +44,19 @@ volumes:
 
 # Registry
 #
-# The Docker registry configuration, see kamal docs registry:
+# The Docker registry configuration, see dash docs registry:
 registry:
   ...
 
 # Servers
 #
-# The servers to deploy to, optionally with custom roles, see kamal docs servers:
+# The servers to deploy to, optionally with custom roles, see dash docs servers:
 servers:
   ...
 
 # Environment variables
 #
-# See kamal docs env:
+# See dash docs env:
 env:
   ...
 
@@ -81,7 +81,7 @@ asset_path: /path/to/assets
 
 # Hooks path
 #
-# Path to hooks, defaults to `.kamal/hooks`.
+# Path to hooks, defaults to `.dash/hooks` (`.kamal/hooks` is still read when only that exists).
 # See https://kamal-deploy.org/docs/hooks for more information:
 hooks_path: /user_home/kamal/hooks
 
@@ -106,8 +106,8 @@ hooks_output:
 
 # Secrets path
 #
-# Path to secrets, defaults to `.kamal/secrets`.
-# Kamal looks for `<secrets_path>-common` first and then `<secrets_path>`.
+# Path to secrets, defaults to `.dash/secrets` (`.kamal/secrets` is still read when only that exists).
+# dash looks for `<secrets_path>-common` first and then `<secrets_path>`.
 # When using destinations, it instead looks for `<secrets_path>-common` first and then
 # `<secrets_path>.<destination>`. Later files override earlier ones.
 secrets_path: /user_home/kamal/secrets
@@ -171,59 +171,66 @@ stop_timeout: 30
 
 # Run directory
 #
-# Directory to store kamal runtime files in on the host, default `.kamal`:
-run_directory: /etc/kamal
+# Where dash keeps its runtime files on each host — per-app env and assets, the
+# proxy's boot files and apps-config mount, loadbalancer service claims, deploy
+# locks, and the audit log. Resolved against the SSH user's home, default
+# `.dash`. A host still holding the pre-3.4 `.kamal` directory is renamed to
+# `.dash` in place the next time dash takes a lock on it; nothing is rebooted.
+#
+# The key is accepted but not yet honoured — the path is currently always
+# `.dash`. Tracked separately from the stage-3 rename.
+run_directory: .dash
 
 # SSH options
 #
-# See kamal docs ssh:
+# See dash docs ssh:
 ssh:
   ...
 
 # Builder options
 #
-# See kamal docs builder:
+# See dash docs builder:
 builder:
   ...
 
 # Accessories
 #
-# Additional services to run in Docker, see kamal docs accessory:
+# Additional services to run in Docker, see dash docs accessory:
 accessories:
   ...
 
 # Proxy
 #
-# Configuration for kamal-proxy, see kamal docs proxy:
+# Configuration for kamal-proxy, see dash docs proxy:
 proxy:
   ...
 
 # SSHKit
 #
-# See kamal docs sshkit:
+# See dash docs sshkit:
 sshkit:
   ...
 
 # Boot options
 #
-# See kamal docs boot:
+# See dash docs boot:
 boot:
   ...
 
 # Logging
 #
-# Docker logging configuration, see kamal docs logging:
+# Docker logging configuration, see dash docs logging:
 logging:
   ...
 
 # Output
 #
-# Configure output loggers (OTel, file), see kamal docs output:
+# Configure output loggers (OTel, file), see dash docs output:
 output:
   ...
 
 # Aliases
 #
-# Alias configuration, see kamal docs alias:
+# Alias configuration, see dash docs alias:
 aliases:
   ...

data/lib/{kamal → dash}/configuration/docs/env.yml

@@ -1,7 +1,7 @@
 # Environment variables
 #
-# Environment variables can be set directly in the Kamal configuration or
-# read from `.kamal/secrets`.
+# Environment variables can be set directly in the dash configuration or
+# read from `.dash/secrets`.
 
 # Reading environment variables from the configuration
 #
@@ -14,33 +14,33 @@ env:
 
 # Secrets
 #
-# Kamal uses dotenv to automatically load environment variables from the configured secrets files.
+# dash uses dotenv to automatically load environment variables from the configured secrets files.
 #
-# Common secrets across all destinations can be set in `.kamal/secrets-common`. Kamal looks for
-# `.kamal/secrets-common` first, then `.kamal/secrets`, with later values overriding earlier ones.
+# Common secrets across all destinations can be set in `.dash/secrets-common`. dash looks for
+# `.dash/secrets-common` first, then `.dash/secrets`, with later values overriding earlier ones.
 #
-# If you are using destinations, Kamal looks for `.kamal/secrets-common` first, then
-# `.kamal/secrets.<destination>`. The non-destination `.kamal/secrets` file is not read when a
+# If you are using destinations, dash looks for `.dash/secrets-common` first, then
+# `.dash/secrets.<destination>`. The non-destination `.dash/secrets` file is not read when a
 # destination is selected.
 #
-# This file can be used to set variables like `KAMAL_REGISTRY_PASSWORD` or database passwords.
+# This file can be used to set variables like `DASH_REGISTRY_PASSWORD` or database passwords.
 # You can use variable or command substitution in the secrets file.
 #
 # ```shell
-# KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
+# DASH_REGISTRY_PASSWORD=$DASH_REGISTRY_PASSWORD
 # RAILS_MASTER_KEY=$(cat config/master.key)
 # ```
 #
 # You can also use [secret helpers](../../commands/secrets) for some common password managers.
 #
 # ```shell
-# SECRETS=$(kamal secrets fetch ...)
+# SECRETS=$(dash secrets fetch ...)
 #
-# REGISTRY_PASSWORD=$(kamal secrets extract REGISTRY_PASSWORD $SECRETS)
-# DB_PASSWORD=$(kamal secrets extract DB_PASSWORD $SECRETS)
+# REGISTRY_PASSWORD=$(dash secrets extract REGISTRY_PASSWORD $SECRETS)
+# DB_PASSWORD=$(dash secrets extract DB_PASSWORD $SECRETS)
 # ```
 #
-# If you store secrets directly in `.kamal/secrets`, ensure that it is not checked into version control.
+# If you store secrets directly in `.dash/secrets`, ensure that it is not checked into version control.
 #
 # To pass the secrets, you should list them under the `secret` key. When you do this, the
 # other variables need to be moved under the `clear` key.
@@ -62,10 +62,10 @@ env:
 # on the context.
 #
 # ```shell
-# SECRETS=$(kamal secrets fetch ...)
+# SECRETS=$(dash secrets fetch ...)
 #
-# MAIN_DB_PASSWORD=$(kamal secrets extract MAIN_DB_PASSWORD $SECRETS)
-# SECONDARY_DB_PASSWORD=$(kamal secrets extract SECONDARY_DB_PASSWORD $SECRETS)
+# MAIN_DB_PASSWORD=$(dash secrets extract MAIN_DB_PASSWORD $SECRETS)
+# SECONDARY_DB_PASSWORD=$(dash secrets extract SECONDARY_DB_PASSWORD $SECRETS)
 # ```
 env:
   secret:
@@ -87,7 +87,7 @@ accessories:
 # Tags
 #
 # Tags are used to add extra env variables to specific hosts.
-# See kamal docs servers for how to tag hosts.
+# See dash docs servers for how to tag hosts.
 #
 # Tags are only allowed in the top-level env configuration (i.e., not under a role-specific env).
 #

data/lib/{kamal → dash}/configuration/docs/proxy.yml

@@ -16,7 +16,7 @@ proxy:
   # Where each option lives when a loadbalancer fronts the fleet
   #
   # Every deploy option has exactly one home (see
-  # Kamal::Configuration::Proxy::DEPLOY_OPTION_DISPOSITIONS - the layering
+  # Dash::Configuration::Proxy::DEPLOY_OPTION_DISPOSITIONS - the layering
   # contract that enforces this):
   #
   #   edge     - applied only by the loadbalancer, stripped from the per-host
@@ -71,46 +71,46 @@ proxy:
   # for multi-host primary roles.
   loadbalancer: lb.example.com
 
-  # Sharing one loadbalancer between several kamal apps
+  # Sharing one loadbalancer between several dash apps
   #
-  # More than one kamal app may point `loadbalancer:` at the same host. Each app
+  # More than one dash app may point `loadbalancer:` at the same host. Each app
   # registers its own service on the shared kamal-proxy and keeps its own
   # deploy.yml; the load balancer multiplexes them by hostname.
   #
-  # The rules kamal enforces for that topology:
+  # The rules dash enforces for that topology:
   #
   # * Service state survives a reboot. kamal-proxy persists its services in the
   #   `kamal-loadbalancer-config` volume (or `kamal-proxy-config` when the
-  #   loadbalancer shares a proxy host), and `kamal proxy reboot` only replaces
+  #   loadbalancer shares a proxy host), and `dash proxy reboot` only replaces
   #   the container. Rebooting from app A does not drop app B's routes — the
   #   surviving service list is printed after the restart.
   #
   # * Service names must be unique across apps. The loadbalancer registers a
   #   service under the bare `service:` name, so two apps — or two destinations
   #   of one app — sharing a name would take over each other's routes. The first
-  #   app to deploy claims the name in `.kamal/loadbalancer/services/<service>`
+  #   app to deploy claims the name in `.dash/loadbalancer/services/<service>`
   #   on the loadbalancer host; a second app deploying the same name fails at
   #   deploy time instead of silently winning.
   #
   # * Apps sharing a loadbalancer must agree on `proxy/run`. All of them boot the
   #   same container, so the first app to boot records its run configuration in
-  #   `.kamal/loadbalancer/run_config`. Another app booting with a different
+  #   `.dash/loadbalancer/run_config`. Another app booting with a different
   #   `proxy/run` fails; the same app changing its own gets the usual drift
-  #   warning and applies it on `kamal proxy reboot`.
+  #   warning and applies it on `dash proxy reboot`.
   #
-  # * `kamal proxy remove` refuses while other apps are installed on the
+  # * `dash proxy remove` refuses while other apps are installed on the
   #   loadbalancer host, exactly as it does for a proxy host. Use `--force` to
   #   override, which removes the shared loadbalancer for every app on it.
 
   # Automatic proxy reboot on deploy
   #
-  # When `kamal deploy` detects that the running kamal-proxy container was
+  # When `dash deploy` detects that the running kamal-proxy container was
   # started with a different image, version or run options than the current
   # configuration, it reboots the proxy automatically — one host at a time —
   # before booting the app.
   #
   # Set to false to opt out. Kamal will then print a warning when drift is
-  # detected and leave the proxy untouched until you run `kamal proxy reboot`.
+  # detected and leave the proxy untouched until you run `dash proxy reboot`.
   #
   # Root-level `proxy` setting only; ignored inside role-specific proxy blocks.
   #
@@ -155,14 +155,14 @@ proxy:
   # in an incoming handshake. A path is resolved against a healthy app target; an
   # absolute http(s) URL is called directly. Answer 2xx to approve. On-demand TLS
   # replaces the static hostname list, so it cannot be combined with
-  # `host`/`hosts`, with `certificate_pem`, or with `ssl_domains` — kamal rejects
+  # `host`/`hosts`, with `certificate_pem`, or with `ssl_domains` — dash rejects
   # those at config time, because kamal-proxy would reject the deploy and there
   # is no sensible winner to pick.
   #
   # `client_ca_pem` requires mutual TLS: clients must present a certificate
   # signed by this CA bundle. Like `certificate_pem` it names a secret in
-  # `.kamal/secrets`; the content is uploaded next to the app's TLS material
-  # under `.kamal/proxy/apps-config`, and the proxy is given the path it sees
+  # `.dash/secrets`; the content is uploaded next to the app's TLS material
+  # under `.dash/proxy/apps-config`, and the proxy is given the path it sees
   # inside its own container. An empty secret fails the deploy rather than
   # silently turning mTLS off.
   ssl:
@@ -258,7 +258,7 @@ proxy:
   # whitespace trimmed. A value may contain colons — a CSP naming a scheme or a
   # port survives intact.
   #
-  # Two things kamal rejects rather than letting them fail late: a value with a
+  # Two things dash rejects rather than letting them fail late: a value with a
   # newline or carriage return in it (that is response splitting, and shell
   # escaping would silently turn it into a literal backslash-n), and a *request*
   # rule naming `Host` — Go carries the host outside the header map, so the rule
@@ -377,7 +377,7 @@ proxy:
   #
   # Set exactly one of `password_secret` or `password` — never both.
   #
-  # Prefer `password_secret`: it names an entry in `.kamal/secrets`, so the
+  # Prefer `password_secret`: it names an entry in `.dash/secrets`, so the
   # password never lives in this file.
   #
   #     basic_auth:
@@ -450,7 +450,7 @@ proxy:
   # `header` names the header carrying the original client IP (`CF-Connecting-IP`
   # behind Cloudflare, `True-Client-IP` behind some others); kamal-proxy reads it
   # instead of `X-Forwarded-For`. It is only honoured when `trusted_proxies` is
-  # set, because otherwise it is just something the client wrote — kamal rejects
+  # set, because otherwise it is just something the client wrote — dash rejects
   # that combination rather than appearing to honour it.
   #
   # Addresses and ranges are plain IPv4/IPv6 or CIDR. Write IPv4 as IPv4, not as
@@ -501,7 +501,7 @@ proxy:
   #
   # Refuse requests whose full User-Agent matches one of these RE2 patterns,
   # checked after the IP rules. A missing User-Agent only matches an explicit
-  # '^$' pattern. Patterns are matched by kamal-proxy (Go RE2), so kamal checks
+  # '^$' pattern. Patterns are matched by kamal-proxy (Go RE2), so dash checks
   # only their shape, not their syntax.
   deny_user_agents:
     - 'BadBot/.*'
@@ -509,7 +509,7 @@ proxy:
   # ### Notes
   # - The health check path is served without an address check and without a rate
   #   limit, so it stays reachable during a deploy. That means it cannot be `/` —
-  #   kamal rejects `healthcheck: path: /` while either feature is on, because it
+  #   dash rejects `healthcheck: path: /` while either feature is on, because it
   #   would leave the whole service open. The default `/up` is fine.
   # - When a loadbalancer is configured, all of this moves to the loadbalancer:
   #   the per-host proxies see the loadbalancer as their peer, so an allow list
@@ -681,17 +681,17 @@ proxy:
   #
   # ### Administering it
   #
-  # `kamal proxy cache stats` reports what the cache is holding (add `--count`
+  # `dash proxy cache stats` reports what the cache is holding (add `--count`
   # to measure entries and bytes per service, `--json` for the raw report),
-  # and `kamal proxy cache purge` drops this app's cached responses
+  # and `dash proxy cache purge` drops this app's cached responses
   # (`--path-prefix /assets` to narrow it). Both run on the layer that owns
   # the cache - the loadbalancer when load balancing, else each proxy host.
   #
   # ### When it is not caching
   #
   # A cache that quietly stores nothing is the usual first surprise. Start with
-  # `kamal proxy cache stats`; kamal-proxy also explains every refusal — check
-  # `kamal proxy logs` for the reason, and the `cache_refusals_total` metric
+  # `dash proxy cache stats`; kamal-proxy also explains every refusal — check
+  # `dash proxy logs` for the reason, and the `cache_refusals_total` metric
   # (by `reason`) if you run with `metrics_port`.
   # The common reasons are a missing `Cache-Control: public, max-age=...` on the
   # app's response, a `Set-Cookie` header, a body over `max_body`, and
@@ -792,7 +792,7 @@ proxy:
   #
   # Stopping and starting containers means talking to the runtime, so the proxy
   # must have been booted with `run/docker_socket` set. That is a boot-time
-  # prerequisite for a deploy-time setting, so kamal checks it while reading this
+  # prerequisite for a deploy-time setting, so dash checks it while reading this
   # file rather than letting the first request hang.
   #
   # Setting `run/docker_socket` also mounts that socket into the proxy container
@@ -832,9 +832,9 @@ proxy:
                                    # `repository` to a host-less path (e.g.
                                    # myfork/kamal-proxy) - the default repository
                                    # below already embeds its ghcr.io host
-    repository: ghcr.io/zoolutions/kamal-proxy # Container repository for the
+    repository: ghcr.io/zoolutions/dash-proxy # Container repository for the
                                    # kamal-proxy image (this is the default)
-    version: v1.0.0.5              # Version tag of the kamal-proxy image to use.
+    version: v1.0.0.7              # Version tag of the kamal-proxy image to use.
                                    # Defaults to the minimum version this gem
                                    # requires - only pin it to roll forward early,
                                    # never below the default
@@ -880,7 +880,29 @@ proxy:
     # staging environment while you are working out a DNS setup, so you do not
     # burn production rate limits on failed attempts.
     #
-    # `credentials` names entries in `.kamal/secrets` to pass to the proxy
+    # `release_probe_interval` is how often, in seconds, the proxy re-checks a
+    # domain whose issuance is currently held - which is what decides how long
+    # after a DNS cutover the certificate appears (proxy v1.0.0.7+).
+    #
+    # You can point a host at dash before its DNS is repointed. No certificate
+    # is ordered until the first HTTPS request arrives, and the proxy first
+    # checks that the domain actually routes back to it - because until it does,
+    # an HTTP-01 challenge cannot succeed, and a failed attempt burns Let's
+    # Encrypt's limit of five failed authorizations per hostname per hour.
+    # Tripping that limit is what would otherwise delay the certificate at the
+    # moment of the cutover. Held domains are re-checked on this interval and
+    # issued as soon as the domain arrives, so the cutover costs one interval
+    # rather than a backoff step.
+    #
+    # The default is 60. A negative value switches release probing off, leaving
+    # a held domain to wait out its backoff. Zones covered by a DNS-01 provider
+    # skip all of this: DNS-01 never depends on where a domain points, so their
+    # certificates can be issued well before a cutover.
+    #
+    # `dash proxy domains list` shows what is held and why; `dash proxy domains
+    # retry HOST` clears a hold when you already know the cause is fixed.
+    #
+    # `credentials` names entries in `.dash/secrets` to pass to the proxy
     # container as environment variables - the API credentials your DNS provider
     # needs (`CF_DNS_API_TOKEN`, `LOOPIA_API_USER`, ...). Name them exactly as the
     # provider expects them, since the name is what reaches the container.
@@ -890,7 +912,7 @@ proxy:
     # zone, and `docker run --env` would leave it in process listings and audit
     # logs. Adding or renaming one changes the proxy's config digest, so the next
     # deploy reboots the proxy to pick it up; rotating a value does not, so run
-    # `kamal proxy reboot` yourself after a rotation.
+    # `dash proxy reboot` yourself after a rotation.
     acme:
       email: admin@example.com
       dns_provider:
@@ -899,6 +921,7 @@ proxy:
         default: route53
       prefer_wildcard: true
       http_fallback: false
+      release_probe_interval: 60
       directory: https://acme-staging-v02.api.letsencrypt.org/directory
       credentials:
         - CF_DNS_API_TOKEN
@@ -1035,12 +1058,12 @@ proxy:
     # `rediss://` URL that every proxy pointed at it shares, so one fetch warms
     # the whole fleet.
     #
-    # The URL never appears on the proxy's command line: kamal delivers it as
+    # The URL never appears on the proxy's command line: dash delivers it as
     # `CACHE_STORE` in a 0600 env file on the host (alongside any ACME
     # credentials), so a password in the URL stays out of process listings and
     # kamal's audit log. The trade-off, same as the ACME credentials: changing
     # only the URL's *value* does not move the drift digest — run
-    # `kamal proxy reboot` after rotating it.
+    # `dash proxy reboot` after rotating it.
     #
     # `store_timeout` only matters with a shared store, in seconds: how long
     # the store may take to answer before the request goes to the app instead —

data/lib/{kamal → dash}/configuration/docs/registry.yml

@@ -4,7 +4,7 @@
 
 # Using a local container registry
 #
-# If the registry server starts with `localhost`, Kamal will start a local Docker registry
+# If the registry server starts with `localhost`, dash will start a local Docker registry
 # on that port and push the app image to it.
 registry:
   server: localhost:5555
@@ -15,13 +15,13 @@ registry:
 # set up a private repository before deploying, or change the default repository privacy
 # settings to private in your [Docker Hub settings](https://hub.docker.com/repository-settings/default-privacy).
 #
-# A reference to a secret (in this case, `KAMAL_REGISTRY_PASSWORD`) will look up the secret
+# A reference to a secret (in this case, `DASH_REGISTRY_PASSWORD`) will look up the secret
 # in the local environment:
 registry:
   username:
     - <your docker hub username>
   password:
-    - KAMAL_REGISTRY_PASSWORD
+    - DASH_REGISTRY_PASSWORD
 
 # Using AWS ECR as the container registry
 #
@@ -45,7 +45,7 @@ registry:
 # base64 -i /path/to/key.json | tr -d "\\n"
 # ```
 #
-# You'll then need to set the `KAMAL_REGISTRY_PASSWORD` secret to that value.
+# You'll then need to set the `DASH_REGISTRY_PASSWORD` secret to that value.
 #
 # Use the environment variable as the password along with `_json_key_base64` as the username.
 # Here’s the final configuration:
@@ -53,12 +53,12 @@ registry:
   server: <your registry region>-docker.pkg.dev
   username: _json_key_base64
   password:
-    - KAMAL_REGISTRY_PASSWORD
+    - DASH_REGISTRY_PASSWORD
 
 # Validating the configuration
 #
 # You can validate the configuration by running:
 #
 # ```shell
-# kamal registry login
+# dash registry login
 # ```

data/lib/{kamal → dash}/configuration/docs/role.yml

@@ -15,7 +15,7 @@ servers:
   #
   # This can be a list of hosts if you don't need custom configuration for the role.
   #
-  # You can set tags on the hosts for custom env variables (see kamal docs env):
+  # You can set tags on the hosts for custom env variables (see dash docs env):
   web:
     - 172.1.0.1
     - 172.1.0.2: experiment1

data/lib/{kamal → dash}/configuration/docs/servers.yml

@@ -11,7 +11,7 @@ servers:
 
 # Tagging servers
 #
-# Servers can be tagged, with the tags used to add custom env variables (see kamal docs env).
+# Servers can be tagged, with the tags used to add custom env variables (see dash docs env).
 servers:
   - 172.0.0.1
   - 172.0.0.2: experiments
@@ -19,7 +19,7 @@ servers:
 
 # Roles
 #
-# For more complex deployments (e.g., if you are running job hosts), you can specify roles and configure each separately (see kamal docs role):
+# For more complex deployments (e.g., if you are running job hosts), you can specify roles and configure each separately (see dash docs role):
 servers:
   web:
     ...

data/lib/{kamal → dash}/configuration/env/tag.rb

@@ -1,4 +1,4 @@
-class Kamal::Configuration::Env::Tag
+class Dash::Configuration::Env::Tag
   attr_reader :name, :config, :secrets
 
   def initialize(name, config:, secrets:)
@@ -8,6 +8,6 @@ class Kamal::Configuration::Env::Tag
   end
 
   def env
-    Kamal::Configuration::Env.new(config: config, secrets: secrets)
+    Dash::Configuration::Env.new(config: config, secrets: secrets)
   end
 end

data/lib/{kamal → dash}/configuration/env.rb

@@ -1,15 +1,15 @@
-class Kamal::Configuration::Env
-  include Kamal::Configuration::Validation
+class Dash::Configuration::Env
+  include Dash::Configuration::Validation
 
   attr_reader :context, :clear, :secrets, :secret_keys
-  delegate :argumentize, to: Kamal::Utils
+  delegate :argumentize, to: Dash::Utils
 
   def initialize(config:, secrets:, context: "env")
     @clear = config.fetch("clear", config.key?("secret") || config.key?("tags") ? {} : config)
     @secrets = secrets
     @secret_keys = config.fetch("secret", [])
     @context = context
-    validate! config, context: context, with: Kamal::Configuration::Validator::Env
+    validate! config, context: context, with: Dash::Configuration::Validator::Env
   end
 
   def clear_args
@@ -17,7 +17,7 @@ class Kamal::Configuration::Env
   end
 
   def secrets_io
-    Kamal::EnvFile.new(aliased_secrets).to_io
+    Dash::EnvFile.new(aliased_secrets).to_io
   end
 
   def merge(other)