Skip to main content
This page collects the main security controls for a self-hosted deployment in one place. Each section links to the detailed setup guide.

​
Restrict who can sign up

By default, anyone who can reach your deployment can create an account. Restrict sign-up to your organization with either or both of these variables:
These only block the creation of new accounts. Existing users keep access, so set them before you invite anyone. See Environment Variables. You can also enforce this at the identity provider:
  • Google: set the OAuth consent screen to Internal so only your Google Workspace users can sign in. See Google OAuth setup.
  • Microsoft: register the app as Single tenant so only your Microsoft Entra ID tenant can sign in. See Microsoft OAuth setup.
Inbox Zero also supports SAML SSO and SCIM provisioning. See Enterprise SSO and SCIM.

​
Keep the app on a private network

For the strongest setup, deploy Inbox Zero on a private network so employees can only reach it through your VPN or a zero-trust access proxy (for example Cloudflare Access or Tailscale). Sign-in still works in this setup because OAuth and SAML redirects run in the user’s browser, which is already on your network. Some features, however, depend on external services calling into your deployment. Those endpoints must stay publicly reachable, or you need to route them through a relay: Each of these endpoints verifies that requests come from the expected service, using a shared secret, request signature, or signed token, and rejects anything that fails. The one exception is GOOGLE_PUBSUB_VERIFICATION_TOKEN: setting it to an empty string turns off Gmail webhook verification, so only do that when a gateway in front of the app already authenticates those requests. If AI assistants or scripts outside your network use the MCP server or API, they also need access. Only expose the endpoints for features you use. Without the mail webhooks, Inbox Zero will not process new email as it arrives. For Gmail on AWS, the webhook gateway puts a public API Gateway in front of a private load balancer and validates Google’s signed tokens before forwarding requests. The same pattern works for the other endpoints with any reverse proxy or API gateway that only forwards the paths listed above. Outbound traffic is also required: to Google or Microsoft APIs, to your AI provider, and to any integrations you enable.

​
Protect secrets

EMAIL_ENCRYPT_SECRET and EMAIL_ENCRYPT_SALT encrypt stored OAuth tokens, which grant access to users’ mailboxes. Keep them, along with INTERNAL_API_KEY, CRON_SECRET, database credentials, and OAuth client secrets, in a secret manager, and restrict who can read them. Changing the encryption secrets without a migration forces every user to reconnect their account. See Production Operations.

​
Limit admin access

Users listed in ADMINS can open /admin, which includes SSO and SCIM configuration. Keep this list short.

​
Control what reaches the AI provider

Email content is sent to your configured AI provider. Choose a provider and account whose data retention terms fit your policy, such as your own AWS Bedrock, Azure, or Google Vertex account, or a self-hosted model. See LLM Setup. To redact or block credentials and payment card numbers before they reach the provider, set SENSITIVE_DATA_POLICY_DEFAULT to REDACT or BLOCK. Set NEXT_PUBLIC_SENSITIVE_DATA_POLICY_LOCKED=true to stop users overriding it. See Sensitive Data Protection.

​
Keep rule webhooks off internal addresses

Rules can call external webhooks. By default, Inbox Zero blocks webhooks to private, loopback, and link-local addresses. Leave WEBHOOK_ALLOW_PRIVATE_IPS unset, especially when the app runs inside your internal network, so a rule cannot be used to reach internal services.

​
Database and backups

Encrypt the database at rest and in transit, and keep tested backups outside the application host. See Production Operations.