-
Notifications
You must be signed in to change notification settings - Fork 520
Add Render deployment configuration #533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Configure Render Blueprint for one-click deployment: - Rails web service (Docker runtime) - Sidekiq background worker - PostgreSQL 16 database - External Redis (Redis Cloud free tier) Cost: $0/month using all free tiers 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
📝 WalkthroughWalkthroughA new Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks✅ Passed checks (3 passed)
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (1)
render.yaml (1)
9-22: Consider adding additional production environment variables.For a production Rails deployment, consider configuring:
RAILS_MASTER_KEYor Rails credentials for encrypted secretsRAILS_LOG_LEVEL(info/warn for production)WEB_CONCURRENCY(number of Puma workers)RAILS_MAX_THREADS(threads per worker)- SMTP/email configuration if sending emails
- Action Cable adapter configuration if using WebSockets
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
render.yaml
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: we-promise/sure PR: 0
File: .cursor/rules/project-design.mdc:0-0
Timestamp: 2025-11-24T16:56:30.669Z
Learning: Application behavior is controlled by `Rails.application.config.app_mode` which can be set to either 'managed' (team-operated servers) or 'self_hosted' (user-hosted infrastructure via Docker Compose)
🪛 Checkov (3.2.334)
render.yaml
[medium] 22-23: Basic Auth Credentials
(CKV_SECRET_4)
🔇 Additional comments (3)
render.yaml (3)
49-57: LGTM!Database configuration is appropriate:
- PostgreSQL 16 is current and well-supported
- Preview environment settings with 7-day expiration are reasonable for testing PRs
12-13: No action needed—SELF_HOSTED environment variable correctly maps to app_mode.The configuration is correct. In
config/application.rb,SELF_HOSTED=trueis properly mapped toRails.application.config.app_mode = "self_hosted"via the line:config.app_mode = (ENV["SELF_HOSTED"] == "true" || ENV["SELF_HOSTING_ENABLED"] == "true" ? "self_hosted" : "managed").inquiry
5-8: Configuration is correctly set up.The Dockerfile exists in the repository root, and the Rails 7.2.2 application has the
/uphealth check endpoint properly configured via the built-in Rails health check atrails/health#show(line 360 of config/routes.rb). The render.yaml configuration is compatible with this setup.
| - type: web | ||
| name: sure-web | ||
| env: docker | ||
| region: oregon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Region mismatch will cause significant latency.
The web service and worker are deployed in Oregon (US West), but Redis is hosted in europe-west2-1 (Europe). This geographic distance will introduce substantial latency (150-200ms+) for every Redis operation, negatively impacting:
- Page load times (session/cache reads)
- Background job processing (Sidekiq queue operations)
- Overall application responsiveness
Consider using Render's managed Redis in the same region or relocating the Redis Cloud instance to a US region closer to Oregon.
Also applies to: 20-22
🤖 Prompt for AI Agents
In render.yaml around line 6 (and also apply the same change to lines 20-22),
the region is set to "oregon" while your Redis Cloud instance is in
europe-west2-1 causing high cross-region latency; fix by aligning regions:
either change the region field(s) to the same US region where your Redis
instance is hosted or move the Redis instance to a US region (preferably
Render-managed Redis in the Oregon region) so all services and Redis share the
same region; update render.yaml service and Redis entries accordingly to the
chosen region and redeploy.
| - key: REDIS_URL | ||
| sync: false | ||
| value: "redis://default:wEEMRqyNSyzgCJ39277MKni75wJxizXZ@redis-13179.c335.europe-west2-1.gce.cloud.redislabs.com:13179" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CRITICAL: Remove hardcoded Redis credentials from version control.
The Redis URL contains plaintext credentials that will be committed to the repository and exposed publicly. This is a critical security vulnerability.
🔎 Recommended fix
- key: REDIS_URL
sync: false
- value: "redis://default:wEEMRqyNSyzgCJ39277MKni75wJxizXZ@redis-13179.c335.europe-west2-1.gce.cloud.redislabs.com:13179"Remove the hardcoded value and add the Redis URL through Render's dashboard as a secret environment variable after deployment. Alternatively, use Render's managed Redis service which handles credentials securely.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In render.yaml around lines 20 to 22, the REDIS_URL is hardcoded with plaintext
credentials which must be removed; replace the value entry with no secret in
source control and configure REDIS_URL as a secret environment variable in
Render's dashboard (or switch to Render's managed Redis) so credentials are
injected at runtime rather than stored in the repo. Ensure you also rotate the
exposed credentials immediately and remove them from history if necessary (e.g.,
revoke and recreate the Redis password and purge from git history or force a
commit without the secret).
| - key: REDIS_URL | ||
| sync: false | ||
| value: "redis://default:wEEMRqyNSyzgCJ39277MKni75wJxizXZ@redis-13179.c335.europe-west2-1.gce.cloud.redislabs.com:13179" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CRITICAL: Remove hardcoded Redis credentials from version control.
The Redis URL contains the same plaintext credentials as the web service. This duplicates the security vulnerability and will be committed to the repository.
🔎 Recommended fix
- key: REDIS_URL
sync: false
- value: "redis://default:wEEMRqyNSyzgCJ39277MKni75wJxizXZ@redis-13179.c335.europe-west2-1.gce.cloud.redislabs.com:13179"Remove the hardcoded value and add the Redis URL through Render's dashboard as a secret environment variable, or use Render's managed Redis service.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In render.yaml around lines 45-47, the Redis URL is hardcoded with plaintext
credentials which must be removed; delete the value field from the file and
replace it with a reference to an environment variable (set the actual REDIS_URL
via Render's dashboard as a secret or use Render's managed Redis service),
ensure the repository only contains the variable name (no secret), and rotate
those exposed Redis credentials immediately to prevent continued compromise.
Configure Render Blueprint for one-click deployment:
Cost: $0/month using all free tiers
🤖 Generated with Claude Code
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.