Start here. This is the direct spoken answer to practice first.
Why this question matters
Stateful local dependencies expose a real trade-off: fast repeatable startup and useful retained data pull in opposite directions. The design needs an intentional reset path and must not let convenient development credentials become a production secret strategy.
I first decide whether the resource should be disposable or preserve state across AppHost runs. Disposable containers give clean, repeatable environments and are useful for automated tests. For day-to-day development, I may use a persistent container lifetime with a named data volume so a database does not rebuild on every restart. A volume is usually more portable and isolated than a host bind mount; I use a bind mount only when developers need direct access to files. Initialization and seed data must be repeatable, and the team needs an obvious reset command when local state becomes stale. Credentials come from Aspire parameters or the normal secret/configuration sources and are passed through references, never committed in AppHost code. Production uses its own managed storage, identity, backup, and secret controls.