Add cron for docker compose self-hosters

[elie222]

Add a Docker Compose cron service that calls GET /api/watch/all every 6 hours for self-hosted deployments

Introduce a background cron container in Docker Compose that hits GET /api/watch/all with CRON_SECRET every 21600 seconds and update hosting docs to reference a consolidated self-hosting guide with a scheduled tasks section.

📍Where to Start

Start with the new cron service definition in docker-compose.yml.

---

Macroscope summarized 71beaab.

Summary by CodeRabbit

• New Features

  • Added scheduled task system to automatically refresh Gmail and Outlook push subscriptions every 6 hours, ensuring continuous email synchronization.

• Documentation

  • Updated self-hosting guides with generalized references and new documentation for configuring scheduled tasks in Docker and non-Docker deployments.

• Chores

  • Version bumped to v2.20.29.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
inbox-zero	Ready	Preview	Nov 26, 2025 5:06pm

[coderabbitai]

Walkthrough

This PR updates documentation to reference a generalized self-hosting guide instead of Docker-specific guides, adds a cron service to docker-compose.yml for periodic API requests, documents the scheduled tasks feature, and increments the version number.

Changes

Cohort / File(s)	Summary
Documentation link consolidation README.md, docs/hosting/aws-copilot.md, docs/hosting/ec2-deployment.md	Updated link references from Docker Self-Hosting Guide (docs/hosting/docker.md) to a generalized Self-Hosting Guide (docs/hosting/self-hosting.md) across multiple documentation files.
Scheduled tasks feature docker-compose.yml	Added new cron service running Alpine Linux that installs curl and executes a loop every 6 hours, making GET requests to http://web:3000/api/watch/all with bearer token authentication. Service depends on web, uses ./apps/web/.env for environment, and restarts automatically.
Scheduled tasks documentation docs/hosting/self-hosting.md	Added new "Scheduled Tasks" section documenting Gmail/Outlook push subscription renewal, cron container setup in Docker Compose, and manual cron job configuration for non-Docker deployments with example cron syntax.
Version increment version.txt	Bumped version from v2.20.28 to v2.20.29.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Verify cron service command syntax (shell loop, curl request format, and timing)
• Confirm depends_on and network configuration for the new cron service
• Validate bearer token environment variable handling (CRON_SECRET from .env)

Possibly related PRs

• Self hosting with docker #760: Directly parallels this PR by consolidating hosting documentation references from Docker-specific guides to a generalized self-hosting guide and adding scheduled task infrastructure.

Poem

🐰 A cron service hops into the fold,
Every six hours, a request so bold,
Docs consolidated, links now shine bright,
v2.20.29—scheduled tasks done right! ⏰

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures the main change: adding a cron service to docker-compose.yml for self-hosters, which is the primary functional addition in the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/docker-compose-cron

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

docker-compose.yml (1)

87-96: Consider enhanced error handling and observability for production deployments. While the current implementation works, adding basic error detection could improve reliability in production:

The curl -s flag suppresses output, which means silent failures if the web service is down or the endpoint returns an error status. For production, consider:

# Current approach (silent failures):
curl -s -X GET 'http://web:3000/api/watch/all' -H "Authorization: Bearer ${CRON_SECRET}"

# Enhanced approach (with status checking and logging):
curl -s -w '\nHTTP Status: %{http_code}\n' -X GET 'http://web:3000/api/watch/all' -H "Authorization: Bearer ${CRON_SECRET}" || echo "[cron] Request failed"

Alternatively, if you're using a structured logging system, the cron output can be captured via Docker's log driver configuration for centralized observability.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e657f9c and 71beaab.

📒 Files selected for processing (6)

• README.md (3 hunks)
• docker-compose.yml (1 hunks)
• docs/hosting/aws-copilot.md (1 hunks)
• docs/hosting/ec2-deployment.md (1 hunks)
• docs/hosting/self-hosting.md (1 hunks)
• version.txt (1 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

!(pages/_document).{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

Don't use the next/head module in pages/_document.js on Next.js projects

Files:

• version.txt
• docs/hosting/self-hosting.md
• docs/hosting/ec2-deployment.md
• README.md
• docker-compose.yml
• docs/hosting/aws-copilot.md

*.md

📄 CodeRabbit inference engine (.cursor/rules/task-list.mdc)

*.md: Create task lists in markdown files named TASKS.md or with a descriptive feature-specific name (e.g., ASSISTANT_CHAT.md) in the project root to track project progress
Structure task list markdown files with sections: Feature Name Implementation (title), description, Completed Tasks, In Progress Tasks, Future Tasks, Implementation Plan, and Relevant Files subsections
Update task list markdown files by marking tasks as completed with [x], adding new identified tasks, and moving tasks between Completed/In Progress/Future sections as appropriate
Keep the 'Relevant Files' section in task list markdown files updated with file paths that have been created or modified, brief descriptions of each file's purpose, and status indicators (e.g., ✅) for completed components

Files:

• README.md

🪛 Gitleaks (8.29.0)

docs/hosting/self-hosting.md

[high] 131-131: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.

(curl-auth-header)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: cubic · AI code reviewer
• GitHub Check: Jit Security
• GitHub Check: Analyze (javascript-typescript)
• GitHub Check: test
• GitHub Check: Review for correctness

🔇 Additional comments (8)

version.txt (1)

1-1: Version bump is appropriate. This minor version increment aligns with the feature addition (cron service).

docs/hosting/aws-copilot.md (1)

185-185: Documentation link reference is updated correctly. The pointer now references the generalized Self-Hosting Guide instead of Docker-specific guidance.

docs/hosting/ec2-deployment.md (1)

136-136: Documentation link correctly points to unified Self-Hosting Guide. This ensures EC2 deployment users have access to the comprehensive self-hosting documentation including cron setup.

docs/hosting/self-hosting.md (2)

124-134: Scheduled Tasks documentation is clear and well-structured. The section effectively explains Gmail/Outlook subscription renewal and provides both Docker Compose and manual setup options.

---

131-131: Address Gitleaks security warning on example curl command. Static analysis flagged line 131 as containing a potential authorization token in the Bearer header. While this is a template with a placeholder (YOUR_CRON_SECRET), the CI/CD pipeline may fail on this. Consider prefixing the line with a comment or clarifying inline that users must replace the placeholder with their actual secret value from .env.

You can verify this by:

1. Confirming whether your CI/CD Gitleaks scan flags this line
2. Checking if CRON_SECRET is properly auto-generated in docker/scripts/setup-env.sh (not visible in provided files)
3. Confirming the /api/watch/all endpoint exists and properly validates the Bearer token

If the CI/CD pipeline blocks on this, consider rephrasing as:

# Example (replace YOUR_CRON_SECRET with the value from .env):
0 */6 * * * curl -s -X GET "https://yourdomain.com/api/watch/all" -H "Authorization: Bearer YOUR_CRON_SECRET"

This makes it explicitly clear that YOUR_CRON_SECRET is a placeholder to be replaced.

README.md (1)

86-86: Documentation links consistently point to unified Self-Hosting Guide. The three updates (lines 86, 306, 379) create a clear documentation hierarchy that directs users to comprehensive guidance regardless of their entry point in the README.

Also applies to: 306-306, 379-379

docker-compose.yml (2)

85-103: Cron service is well-implemented with solid Docker practices. The service correctly depends on the web container, uses the same network, sources secrets from the environment file, and will restart automatically. The 6-hour interval aligns with typical Gmail/Outlook subscription renewal requirements.

---

85-103: Based on my thorough verification of the codebase, here is my rewritten review comment:

---

CRON_SECRET and /api/watch/all endpoint are properly secured and implemented.

The three concerns raised in this review are already correctly addressed in the implementation:

1. CRON_SECRET generation is properly handled: docker/scripts/setup-env.sh (line 74) auto-generates a strong 32-byte random hex secret via generate_secret 32, and the cron container loads it via env_file: ./apps/web/.env.

2. Endpoint authentication and error handling are correctly implemented: /api/watch/all (apps/web/app/api/watch/all/route.ts) validates the Bearer token using hasCronSecret(), captures unauthorized attempts with captureException(), returns 401 status, and logs all failures. The endpoint is idempotent—it renews email watches on each call, making repeated execution safe.

3. Web service dependency resilience is handled appropriately: The shell chain in docker-compose uses && operators, so curl errors cause the chain to fail (not silent failures). Failed requests stop iteration and retry after 6 hours. The watchEmailAccounts function gracefully handles per-account errors and continues processing remaining accounts.

No action needed—the implementation follows security best practices.

[cubic-dev-ai]

No issues found across 6 files

[jit-ci]

❌ The following Jit checks failed to run:

• secret-detection

#jit_bypass_commit in this PR to bypass, Jit Admin privileges required.

More info in the Jit platform.