## What has to be unique

Four things, and each one is a line in the second app's `config/deploy.yml`:

| Setting | Why |
|---|---|
| `service` | Names the containers. A shared name means the second deploy replaces the first. |
| `proxy.host` | How the proxy decides which app gets the request. |
| volume paths | Two apps writing one SQLite file is data loss, not a conflict error. |
| any fixed host port | Only one process can bind a port. |

```bash
bin/kamal app containers
ssh your-server 'docker ps --format "table {{.Names}}\t{{.Ports}}"'
```

Run those before the second deploy. Anything already bound to 443 that is not Kamal's proxy is the
thing that will break.

## The volume line is the one that bites

Volumes are declared per app, and a copied config file keeps the source path of the app it was
copied from:

```yaml
volumes:
  - "second_app_storage:/rails/storage"
```

If both apps mount the same named volume, they open the same database file, and neither one reports
a problem. You find out when rows from one app appear in the other.

## Resources are shared, and nothing enforces a split

Two Rails apps on a 2GB VPS each run Puma workers and Solid Queue in the same container. A memory
spike in one app causes the kernel to kill a process in either. If both apps matter, either size the
box for the sum of both or accept that they share a failure.

`bin/kamal app exec 'free -m'` shows what is actually available, which is usually less than the plan
says once the database and the proxy have their share.

## When to use two servers instead

If the second app is a customer-facing service with its own uptime expectation, put it on its own
host. The saving from co-tenancy is a few dollars a month, and the cost is that one deploy can take
down two products. That trade is usually worth it for a side project and rarely worth it otherwise.