I'd imagine that there will be a much more seamless way once Kamal 2.0 is released. This major update will rely on kamal-proxy (https://github.com/basecamp/kamal-proxy)  which is important for the load balancing aspects.

I like that approach too. I think that it would just depend on my application and the risk involved. By using the base controller, you're still validating that this route potentially exists. Using a constraint, the route would appear like it does not exist at all. So, I guess the best route would be whatever kind of experience you wanted for an unauthorized user.

Here's an example of what the accessory for Postgres could look like. It would rely on you updating the .kamal/secrets to also pass the POSTGRES_PASSWORD for the initial setup. Also, you would want to take care because in this situation, you're exposing port 5432 to the world as well. This shouldn't be an issue if you have a firewall, but you still want to take precautions. You could do something like

127.0.0.1:5432:5432

to expose it only on the localhost, but could have issues if you ever outgrow a single server setup.

# config/deploy.yml
accessories:
  postgres:
    image: postgres:17
    port: 5432:5432
    host: IP_OF_THE_SERVER
    env:
      clear:
        POSTGRES_USER: APPLICATION_NAME
        POSTGRES_DB: APPLICATION_NAME_production
      secret:
        - POSTGRES_PASSWORD
    directories:
      - data:/var/lib/postgresql/data

Running kamal setup will install docker for you automatically as it does detect if it doesn't exist. In the episode example of the DO Droplet, I didn't do any pre-setup or hardening. Kamal installed docker and everything it needed.

Ah, yes that makes sense. Unless there is a remote builder set up, that is correct.