Original Summary

I'm building a self-hosted email service using Gmail IMAP with OAuth2/XOAUTH2 (similar to EmailEngine/IMAPFlow). Google's unverified OAuth app has a 100-user cap. I'm trying to understand how this works in practice when a self-hosted system supports multiple OAuth configurations. For example: PC/server → Docker/Hub A → Google Cloud Project A → up to 100 Gmail accounts → Docker/Hub B → Google Cloud Project B → another set of Gmail accounts Both projects would run from the same physical server and same public IP , but each would have its own Google Cloud project, OAuth client ID/secret, consent configuration, and refresh tokens. My questions: Has anyone actually run more than 100 Gmail accounts this way using EmailEngine, IMAPFlow, an IMAP OAuth proxy, MCP email server, or a similar self-hosted system? Does Google treat the 100-user limit independently per Google Cloud project in practice? Can two separate OAuth projects operate from the same server/public IP without causing OAuth or Gmail IMAP issues? Has anyone used EmailEngine's multiple OAuth-app configuration for this kind of setup? If you've operated 150–500+ Gmail accounts, what architecture/authentication method did you use? Did Google eventually require verification even though the accounts were divided between different OAuth projects? Did you encounter account blocks, OAuth token problems, IMAP connection limits, or Google security warnings? I'm particularly interested in first-hand experience from someone who has actually operated >100 Gmail accounts, rather than just theoretical answers. I'm not looking for ways to hide traffic or bypass Google's enforcement. I'm trying to understand whether multiple OAuth projects are a legitimate supported architecture or whether verification is effectively required once the overall service exceeds 100 users.   submitted by   /u/DesperateMinimum9819 [link]   [comments]

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/9/13 16:09:55