Hi there! I have few questions about self-hosting bots that I have not been able to answer from the code/docs. 1. We have a multi-tenant system with a few standardized bots that every project gets. Currently we are recreating for each project. Can I create the bots in a shared project and then setup the subscriptions in each project? I tried this but wasn't able to get it to work. 2. Does

Bot.system

do anything more than include system secrets for the bot? I have some very sensitive secrets (Stripe keys for example) that I want to move to systemSecrets to reduce visibility. 3. Any other Bot features that would be applicable to self hosting I should be aware of? Thanks!

Hey Doug! Thanks for reaching out about these - answers below: 1. Yes, this is supported - you would need to make sure a 

ProjectMembership

 exists for the bot in each tenant project, with a

user.reference

and

profile.reference

both pointing to the

Bot/<BOT_ID>

. - When a Subscription fires, Medplum looks up a membership for the bot within the subscription's (tenant) project to determine execution context. If none exists, the job fails silently with "Could not find project membership for bot." - Once a

ProjectMembership

 exists for the bot in the tenant project, create your 

Subscription

 in the tenant project with 

channel.endpoint

 set to 

Bot/<BOT_ID>

. One other thing to confirm: the bot's home (shared) project must have the 

bots

 feature enabled - that check always uses the bot's home project regardless of which tenant triggered it. Let me know if you have any additional issues setting this up! 2. No, setting

Bot.system

only includes system secrets at runtime. 3. Some additional self-hosted Bot features that would be useful include cron-execution of Bots (preCommitSubscriptionsEnabled in server config), or pre-commit bots (needs

preCommitSubscriptionsEnabled

enabled in server config). 4. For a more private way of storing secrets other than the system secrets assigned to a Bot, you have a couple of options: - If Bot runtime is

vmcontext

, then your Bots have access to env variables that can be injected at server deploy time. - use an external secrets manager (like AWS Secrets Manager, HashiCorp Vault, etc.)

Ahah! The

ProjectMembership

was the part I was missing for shared Bots. Also thank you for the preCommit interceptor reminder. I think I saw that flag when reviewing the server config but didn't dig too far into it. I see the relevant files in the repo, is there any more documentation on this? Since all of our secrets are on a per-project basis, I'll have to think on the best way to manage very sensitive secrets.

systemSecret

is definitely better than project secrets. I'm just spit-balling but one way I could tenant the secrets would be to use parameter store and nest every project's secrets under that project's ID. E.g.

/projects/:id/*

but then the only thing preventing a bot in one project from accessing those is that it doesn't know the project id. I need to sit with that to see how I feel about it Thank you!