Would multi-channel support fit the project direction?

[JoAdo07]

Context

I’ve been reading through the project and the single-channel assumption looks deliberate rather than accidental. The dashboard, scheduler, and database all appear to operate on one active channel.

For example, database/db.js stores the channel profile and strategy under the fixed primary key default:

• channel_profiles has id TEXT PRIMARY KEY
• getChannelProfile() queries WHERE id = 'default'
• getChannelStrategy() queries WHERE id = 'default'

Credentials and the scheduler also appear to be global to the process. So today, running two channels means running two separate checkouts or processes with separate databases, data directories, and Google OAuth credentials.

Question

Is first-class multi-channel support in scope for the project, or is the intended deployment model intentionally one instance per channel?

I’m asking because the “one instance per channel” model is simple and safe, but it gets awkward for anyone managing multiple channels or brands:

• shared provider keys and budget caps
• one review queue across channels
• channel switching in the dashboard
• per-channel analytics and learning loops
• scheduler isolation so one channel’s failures don’t block another

Possible directions

1. Keep one instance per channel. Document the supported deployment pattern (separate data directory, database, OAuth credentials, and port) and add a small wrapper or Compose example. Lowest risk, no schema migration.
2. Tenant-aware schema. Add a channel_id to the channel-scoped tables and a channel switcher in the dashboard. More useful, but a large migration touching credentials, scheduling, and every query.
3. Hybrid. Keep the current single-channel runtime, but add an explicit “channel workspace” concept that can be started side by side with separate config roots.

I’m not asking for a large refactor. I’d just like to know which direction you’d prefer before anyone spends time on a design or PR. If option 1 is the intended answer, a short deployment note would probably save people from trying to share one database across channels.

What I can help with

If this is in scope, I’m happy to help sketch the smallest useful version and open a focused PR. If it’s out of scope, a brief note in the docs would still be useful.