Clarification Request for Architecture details for the ActivityPub setup (Volumes, DB, and Migrations)

[defame-flagstick]

Hi everyone,

I'm currently looking into the official compose.yml provided here to set up the new ActivityPub integration. While the setup works, it introduces a few structural choices that aren't documented anywhere, which makes customizing or hardening the stack quite difficult for self-hosters.

It would be awesome if we could get a quick section in the README.md or a short architecture note explaining these points:

1. Shared Volumes: Both the "ghost" and "activitypub" containers map to the exact same host directory (${UPLOAD_LOCATION:-./data/ghost}). Why is this required? Does the AP service need direct access to the uploaded images/media to handle federation properly?
2. Database Credentials & Isolation: In the example, both services share the exact same database name and user. For production setups, can we completely isolate them? If I create two separate users and two separate databases (e.g., "ghost_prod" and "ghost_ap"), does either service actually need read or write access to the other service's database? Or is all communication handled via HTTP (ACTIVITYPUB_TARGET) anyway?
3. Images SHA Hashes: The compose file uses two distinct images: "activitypub" and "activitypub-migrations". Both are tagged with the same version (1.2.5), but they use completely different SHA256 hashes. Why is this the case or just an inconsistency?

Having a bit more context on how these components interact would be helpful for anyone running customized Docker stacks, external databases, or Kubernetes.

Thanks!

[defame-flagstick]

To answer my second question:
I tested it with isolated user credentials and it was working fine.