Add SMTP Changes and step on local host #8502
Conversation
|
|
📝 WalkthroughWalkthroughThis PR introduces Docker Compose configurations and environment files for Plane app deployments, establishing multi-service orchestration with database, Redis, RabbitMQ, MinIO, and API services. Updates existing environment variables from multi-host defaults to localhost-oriented configuration. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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.
This PR is being reviewed by Cursor Bugbot
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| EMAIL_USE_TLS=1 | ||
|
|
||
| EMAIL_HOST_USER=[email protected] | ||
| EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh |
There was a problem hiding this comment.
Hardcoded Gmail credentials committed to repository
High Severity
Real Gmail credentials are committed to the repository. The values [email protected] and EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh appear to be an actual email address and Gmail App Password. These credentials are now exposed in version control and need to be rotated immediately. Environment files with real secrets should use placeholders or be excluded from version control via .gitignore.
Additional Locations (2)
| AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY:-secret-key} | ||
| AWS_S3_ENDPOINT_URL: ${AWS_S3_ENDPOINT_URL:-http://plane-minio:9000} | ||
| AWS_S3_BUCKET_NAME: ${AWS_S3_BUCKET_NAME:-uploads} | ||
|
|
There was a problem hiding this comment.
Main docker-compose.yaml missing SMTP environment variables
Medium Severity
The main docker-compose.yaml is missing the SMTP environment variables (EMAIL_BACKEND, EMAIL_HOST, EMAIL_PORT, EMAIL_USE_TLS, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, DEFAULT_FROM_EMAIL) that are present in the archived version's x-aws-s3-env block. Even though the .env files define these SMTP settings, they won't be passed to containers because they're not declared in the compose file's environment sections. Email functionality will not work.
| LIVE_SERVER_SECRET_KEY= | ||
| DOCKERHUB_USER=artifacts.plane.so/makeplane | ||
| PULL_POLICY=if_not_present | ||
| CUSTOM_BUILD=false |
There was a problem hiding this comment.
Backup and save files accidentally committed
Low Severity
Backup files (plane.env.bak and variables.env.save) have been committed to the repository. These appear to be editor backup or temporary files that shouldn't be in version control. They also contain the same hardcoded credentials, duplicating the security exposure.
Additional Locations (1)
| # ========================= | ||
| # SECURITY | ||
| # ========================= | ||
| SECRET_KEY=dev-secret |
There was a problem hiding this comment.
Weak SECRET_KEY value in deployment configuration
High Severity
The SECRET_KEY has been changed from a proper random string to dev-secret. Django's SECRET_KEY is used for cryptographic signing of sessions, CSRF tokens, and password reset tokens. Using a trivially guessable value like "dev-secret" makes the application vulnerable to session hijacking, CSRF attacks, and forged password reset links. Even for local development, this value is unsafe as it may accidentally be used in production deployments.
Additional Locations (1)
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 Fix all issues with AI agents
In @deployments/cli/community/plane-app/archive/1767865532.docker-compose.yaml:
- Around line 27-34: The SMTP settings are placed in the x-aws-s3-env anchor and
contain hardcoded Gmail values; extract these into a new reusable anchor named
x-smtp-env with environment-variable placeholders for EMAIL_BACKEND, EMAIL_HOST,
EMAIL_PORT, EMAIL_USE_TLS, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, and
DEFAULT_FROM_EMAIL, remove the SMTP keys from x-aws-s3-env, and update any
services that need email to include the new anchor by merging *smtp-env into
their environment sections so providers can be swapped via env vars without
editing the compose file.
In @deployments/cli/community/plane-app/archive/1767865532.env:
- Line 73: Remove the hardcoded SECRET_KEY entry and stop committing secrets to
repo; rotate the exposed SECRET_KEY immediately if it was used in any deployed
environment, then update your Django configuration (e.g., the module that
currently assigns SECRET_KEY) to read the secret from the environment at runtime
(os.environ or a secrets manager) and ensure the env var name remains SECRET_KEY
(or another agreed name) so deployments inject it securely; also add the env
file to .gitignore and update docs/CI to use secure secret provisioning.
- Around line 46-56: Remove the hardcoded Gmail credentials by replacing the
literal values for EMAIL_HOST_USER and EMAIL_HOST_PASSWORD with environment
variable placeholders (e.g., EMAIL_HOST_USER=${EMAIL_HOST_USER} and
EMAIL_HOST_PASSWORD=${EMAIL_HOST_PASSWORD}) and change DEFAULT_FROM_EMAIL to
reference the same env var or a separate DEFAULT_FROM_EMAIL placeholder; add the
actual .env file to .gitignore, add a sanitized .env.example with placeholder
values and instructions, and after making these changes immediately
rotate/revoke the exposed Gmail app password and document the credential
rotation; lastly, purge the secret from git history (e.g., BFG or git
filter-branch) and notify the security/owner to validate account compromise.
In @deployments/cli/community/plane-app/docker-compose.yaml:
- Around line 4-5: The compose file currently supplies weak fallback credentials
(POSTGRES_USER, POSTGRES_PASSWORD, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,
SECRET_KEY, LIVE_SERVER_SECRET_KEY); remove or restrict these insecure defaults
by making them development-only (e.g., load defaults from a separate .env.dev or
wrap in a conditional for local compose), require explicit environment values
for production (no fallbacks) and/or fail fast if missing, and add inline
comments next to each variable (for example by editing entries referencing
POSTGRES_USER, POSTGRES_PASSWORD, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,
SECRET_KEY, LIVE_SERVER_SECRET_KEY) warning that the default is insecure and
must be overridden in staging/production and documented in deployment docs.
In @deployments/cli/community/plane-app/plane.env:
- Around line 1-99: Commit contains sensitive deployment env files (plane.env
and plane.env.bak); remove them from VCS and provide a safe template and docs.
Add plane.env and plane.env.bak to .gitignore, remove the committed secrets from
the repo history (e.g., git rm --cached and rewrite history if necessary),
create a sanitized plane.env.example with placeholder values copied from
plane.env (redact real secrets like SECRET_KEY, EMAIL_HOST_PASSWORD,
AWS_SECRET_ACCESS_KEY, LIVE_SERVER_SECRET_KEY, DATABASE_URL, REDIS_URL,
AMQP_URL), and update README/setup docs with steps to copy plane.env.example to
plane.env and never commit it.
- Line 24: Replace the insecure hardcoded POSTGRES_PASSWORD value ("root") with
a non-sensitive placeholder that forces users to supply a strong password (e.g.,
POSTGRES_PASSWORD=<YOUR_SECURE_PASSWORD>) and update the corresponding
DATABASE_URL entry to use that placeholder or to read the password from the same
env var (ensure the DATABASE_URL references POSTGRES_PASSWORD rather than
embedding "root"); ensure documentation or env example makes clear users must
set a strong password before deployment.
- Around line 52-53: This file exposes real Gmail credentials (EMAIL_HOST_USER
and EMAIL_HOST_PASSWORD) and must be removed from VCS: immediately revoke the
exposed Gmail app password, replace the values in plane.env and plane.env.bak
with non-sensitive placeholder values (e.g.,
[email protected], EMAIL_HOST_PASSWORD=your-app-password)
in the repo, add plane.env and plane.env.bak to .gitignore, create
plane.env.example with placeholder entries for documentation, and purge the
secrets from git history using git-filter-repo or BFG Repo-Cleaner so they are
removed from past commits.
- Line 71: Remove the hardcoded SECRET_KEY value and replace it with a
runtime-sourced secret: stop committing literal SECRET_KEY in the ENV (symbol:
SECRET_KEY), change code to read SECRET_KEY from an environment variable or
secrets manager at startup, and store only a placeholder (e.g.,
SECRET_KEY=${SECRET_KEY}) in this file; generate per-environment keys (using
get_random_secret_key()) and inject them via CI/hosting secrets, add the .env
file to .gitignore, and rotate/revoke the exposed key from all environments and
version history as appropriate.
In @deployments/cli/community/plane-app/plane.env.bak:
- Line 82: The env file contains a duplicate setting for MINIO_ENDPOINT_SSL;
remove the redundant entry so only a single MINIO_ENDPOINT_SSL assignment
remains (keep the intended value and delete the other occurrence), ensuring no
duplicate environment keys exist in the file to avoid confusion or unexpected
overrides.
- Around line 52-53: The commit exposes real credentials in the environment
backup—replace the values of EMAIL_HOST_USER and EMAIL_HOST_PASSWORD with
placeholders (e.g. [email protected] and
EMAIL_HOST_PASSWORD=REPLACE_ME), add plane.env and plane.env.bak to .gitignore,
create a plane.env.example with placeholder values and documentation, revoke the
exposed Gmail app password immediately, and remove the secrets from repository
history using git-filter-repo or BFG Repo-Cleaner to purge
EMAIL_HOST_USER/EMAIL_HOST_PASSWORD from past commits.
- Line 73: Hardcoded SECRET_KEY exposed in the repo (the SECRET_KEY line) must
be removed; replace the hardcoded value with reading from an environment
variable (e.g., DJANGO_SECRET_KEY) and fail fast if missing, rotate the current
key, remove the SECRET_KEY entry from version control, and move the new
per-environment keys into a secrets manager (AWS Secrets Manager/HashiCorp
Vault) so deployments load the key from secure storage rather than from the
file.
- Line 24: The POSTGRES_PASSWORD entry currently uses a weak hardcoded value
("POSTGRES_PASSWORD=root"); replace this with a placeholder and guidance—e.g.,
change to a non-sensitive placeholder (like
POSTGRES_PASSWORD=__GENERATE_STRONG_PASSWORD__) and add a single-line comment
above or next to the POSTGRES_PASSWORD key recommending users generate a strong,
unique password (and/or use a secrets manager) before deploying; ensure the
symbol POSTGRES_PASSWORD is updated accordingly wherever the env file is
consumed.
In @deployments/cli/community/variables.env:
- Around line 52-54: Replace the placeholder SECRET_KEY with a strong, unique
secret in non-local environments (do not commit dev-secret), remove or narrow
TRUSTED_PROXIES instead of using 0.0.0.0/0 (restrict to known proxy IPs or leave
unset so defaults block spoofing), and ensure SITE_ADDRESS is set appropriately
for production; make these values configurable via environment-specific
overrides or a secret management system so production deployments never use the
dev defaults.
🧹 Nitpick comments (4)
deployments/cli/community/variables.env.save (1)
1-55: Clarify the purpose and usage of this.savefile.The
.savefile extension is non-standard for environment configuration files. Please clarify:
- Is this a backup, template, or example file?
- How is it meant to be used in the deployment workflow?
- Should it be renamed to follow standard conventions (e.g.,
.env.example,.env.template)?Additionally, this file contains default credentials that are suitable only for local development:
POSTGRES_PASSWORD=rootSECRET_KEY=dev-secretAWS_ACCESS_KEY_ID=minioadmin/AWS_SECRET_ACCESS_KEY=minioadminEnsure these are never used in production or staging environments.
deployments/cli/community/plane-app/docker-compose.yaml (1)
1-255: Missing SMTP configuration compared to archive version.The PR title mentions "Add SMTP Changes" and the archive docker-compose file (1767865532.docker-compose.yaml) includes SMTP environment variables in
x-aws-s3-env. However, this docker-compose.yaml doesn't include any SMTP configuration.Should SMTP environment variables be added to this file as well? If SMTP support is intended for this deployment configuration, consider adding an SMTP anchor similar to:
x-smtp-env: &smtp-env EMAIL_BACKEND: ${EMAIL_BACKEND:-django.core.mail.backends.console.EmailBackend} EMAIL_HOST: ${EMAIL_HOST} EMAIL_PORT: ${EMAIL_PORT:-587} EMAIL_USE_TLS: ${EMAIL_USE_TLS:-1} EMAIL_HOST_USER: ${EMAIL_HOST_USER} EMAIL_HOST_PASSWORD: ${EMAIL_HOST_PASSWORD} DEFAULT_FROM_EMAIL: ${DEFAULT_FROM_EMAIL}And merge it into services that need email functionality.
deployments/cli/community/plane-app/plane.env.bak (1)
59-59: Fix typo in comment.Minor typo: "CERT_EMAIl" should be "CERT_EMAIL".
📝 Proposed fix
-# If SSL Cert to be generated, set CERT_EMAIl="email <EMAIL_ADDRESS>" +# If SSL Cert to be generated, set CERT_EMAIL="email <EMAIL_ADDRESS>"deployments/cli/community/plane-app/plane.env (1)
57-57: Fix typo in comment.Minor typo: "CERT_EMAIl" should be "CERT_EMAIL".
📝 Proposed fix
-# If SSL Cert to be generated, set CERT_EMAIl="email <EMAIL_ADDRESS>" +# If SSL Cert to be generated, set CERT_EMAIL="email <EMAIL_ADDRESS>"
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
deployments/cli/community/plane-app/archive/1767865532.docker-compose.yamldeployments/cli/community/plane-app/archive/1767865532.envdeployments/cli/community/plane-app/docker-compose.yamldeployments/cli/community/plane-app/plane.envdeployments/cli/community/plane-app/plane.env.bakdeployments/cli/community/variables.envdeployments/cli/community/variables.env.save
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: gakshita
Repo: makeplane/plane PR: 7393
File: apps/admin/app/(all)/(dashboard)/email/email-config-form.tsx:104-104
Timestamp: 2025-07-14T11:22:43.964Z
Learning: In the Plane project's SMTP configuration implementation, the email configuration form (email-config-form.tsx) hardcodes ENABLE_SMTP to "1" in form submission because the form is only rendered when SMTP is enabled. The enable/disable functionality is managed at the page level (page.tsx) with a toggle, and the form only handles configuration details when SMTP is already enabled.
Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/bash.instructions.md:0-0
Timestamp: 2025-11-25T10:17:39.709Z
Learning: Applies to docker-compose-local.yml : Use docker-compose-local.yml for local development Docker configuration
Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/bash.instructions.md:0-0
Timestamp: 2025-11-25T10:17:39.709Z
Learning: Applies to docker-compose.yml : Use docker-compose.yml for production and staging Docker configuration
📚 Learning: 2025-11-25T10:17:39.709Z
Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/bash.instructions.md:0-0
Timestamp: 2025-11-25T10:17:39.709Z
Learning: Applies to docker-compose.yml : Use docker-compose.yml for production and staging Docker configuration
Applied to files:
deployments/cli/community/plane-app/archive/1767865532.docker-compose.yamldeployments/cli/community/plane-app/docker-compose.yaml
📚 Learning: 2025-11-25T10:17:39.709Z
Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/bash.instructions.md:0-0
Timestamp: 2025-11-25T10:17:39.709Z
Learning: Applies to docker-compose-local.yml : Use docker-compose-local.yml for local development Docker configuration
Applied to files:
deployments/cli/community/plane-app/archive/1767865532.docker-compose.yamldeployments/cli/community/plane-app/docker-compose.yaml
🪛 Checkov (3.2.334)
deployments/cli/community/plane-app/archive/1767865532.docker-compose.yaml
[medium] 65-66: Basic Auth Credentials
(CKV_SECRET_4)
deployments/cli/community/plane-app/docker-compose.yaml
[medium] 55-56: Basic Auth Credentials
(CKV_SECRET_4)
🪛 Gitleaks (8.30.0)
deployments/cli/community/plane-app/plane.env
[high] 71-71: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
deployments/cli/community/plane-app/archive/1767865532.env
[high] 73-73: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
deployments/cli/community/plane-app/plane.env.bak
[high] 73-73: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
⏰ 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). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (8)
deployments/cli/community/variables.env (2)
1-10: Localhost configuration aligns with PR objectives.The shift to localhost-based configuration (127.0.0.1) for
APP_DOMAIN,WEB_URL,CORS_ALLOWED_ORIGINS, andDEBUG=1is consistent with the PR's goal of enabling local development setup.
14-19: Weak database credentials detected.The database is configured with default credentials (
POSTGRES_USER=postgres,POSTGRES_PASSWORD=root). While acceptable for local development, ensure these are:
- Never used in production or staging environments
- Overridden via environment variables in actual deployments
- Documented as insecure defaults for local development only
deployments/cli/community/plane-app/archive/1767865532.env (1)
1-3: Verify the purpose of this archived configuration file.This file appears to be an archived/versioned environment configuration (based on the timestamp
1767865532in the filename). Please clarify:
- What is the archival strategy and purpose?
- Should sensitive values be included in archived configs?
- Is this meant to be a snapshot or a working configuration?
deployments/cli/community/plane-app/docker-compose.yaml (3)
1-255: Clarify the intended deployment environment for this docker-compose file.Based on learnings, the project convention is:
docker-compose.ymlfor production and stagingdocker-compose-local.ymlfor local developmentThis file is named
docker-compose.yamland contains localhost-oriented defaults (APP_DOMAIN: ${APP_DOMAIN:-localhost},WEB_URL: ${WEB_URL:-http://localhost}), suggesting it's for local development. However, the filename doesn't include the-localsuffix.Please clarify the intended use case and consider renaming if this is meant for local development only.
Based on learnings.
1-61: Well-structured environment variable composition using YAML anchors.The use of YAML anchors (
&db-env,&redis-env, etc.) and merge keys (<<:) provides excellent reusability and maintainability. This approach:
- Centralizes environment configuration
- Reduces duplication across services
- Makes it easy to update shared settings
The environment fallback pattern (
${VAR:-default}) is also well-implemented.
62-170: Service dependencies and startup order properly defined.The
depends_onconfigurations establish appropriate service startup ordering:
- Frontend services (web, space, admin, live) depend on api/worker
- Backend services (api, worker, beat-worker, migrator) depend on infrastructure (plane-db, plane-redis, plane-mq)
This ensures services start in the correct sequence.
deployments/cli/community/plane-app/archive/1767865532.docker-compose.yaml (1)
1-265: Archive docker-compose structure is consistent with main version.This archived version maintains the same well-structured approach as the main docker-compose.yaml:
- YAML anchors for environment reuse
- Proper service dependencies
- Infrastructure service definitions
The primary differences are the SMTP configuration addition (though it needs refactoring) and the archive timestamp in the filename.
deployments/cli/community/plane-app/plane.env.bak (1)
41-41: No action needed—emptyAMQP_URLis intentional.The codebase has fallback logic where
CELERY_BROKER_URLusesAMQP_URLif provided, otherwise constructs it from individual RabbitMQ parameters (RABBITMQ_USER,RABBITMQ_PASSWORD,RABBITMQ_HOST,RABBITMQ_PORT,RABBITMQ_VHOST). Having an emptyAMQP_URLwith individual parameters is the expected configuration pattern.Likely an incorrect or invalid review comment.
| # SMTP (GMAIL) | ||
| EMAIL_BACKEND: django.core.mail.backends.smtp.EmailBackend | ||
| EMAIL_HOST: smtp.gmail.com | ||
| EMAIL_PORT: 587 | ||
| EMAIL_USE_TLS: "1" | ||
| EMAIL_HOST_USER: ${EMAIL_HOST_USER} | ||
| EMAIL_HOST_PASSWORD: ${EMAIL_HOST_PASSWORD} | ||
| DEFAULT_FROM_EMAIL: ${DEFAULT_FROM_EMAIL} |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
SMTP configuration lacks environment variable support.
The SMTP configuration is hardcoded in the x-aws-s3-env anchor without environment variable placeholders:
EMAIL_BACKEND: django.core.mail.backends.smtp.EmailBackend
EMAIL_HOST: smtp.gmail.com
EMAIL_PORT: 587
EMAIL_USE_TLS: "1"
EMAIL_HOST_USER: ${EMAIL_HOST_USER}
EMAIL_HOST_PASSWORD: ${EMAIL_HOST_PASSWORD}
DEFAULT_FROM_EMAIL: ${DEFAULT_FROM_EMAIL}Issues:
- Architectural concern: SMTP configuration is placed in the
aws-s3-envanchor, which is meant for S3/MinIO settings. This is confusing and violates separation of concerns. - Hardcoded values:
EMAIL_BACKEND,EMAIL_HOST,EMAIL_PORT, andEMAIL_USE_TLSare hardcoded to Gmail-specific values, making it difficult to use other SMTP providers without editing the file.
Recommended refactor:
♻️ Create a separate SMTP environment anchor
+x-smtp-env: &smtp-env
+ EMAIL_BACKEND: ${EMAIL_BACKEND:-django.core.mail.backends.smtp.EmailBackend}
+ EMAIL_HOST: ${EMAIL_HOST:-smtp.gmail.com}
+ EMAIL_PORT: ${EMAIL_PORT:-587}
+ EMAIL_USE_TLS: ${EMAIL_USE_TLS:-1}
+ EMAIL_HOST_USER: ${EMAIL_HOST_USER}
+ EMAIL_HOST_PASSWORD: ${EMAIL_HOST_PASSWORD}
+ DEFAULT_FROM_EMAIL: ${DEFAULT_FROM_EMAIL}
+
x-aws-s3-env: &aws-s3-env
AWS_REGION: ${AWS_REGION:-}
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID:-access-key}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY:-secret-key}
AWS_S3_ENDPOINT_URL: ${AWS_S3_ENDPOINT_URL:-http://plane-minio:9000}
AWS_S3_BUCKET_NAME: ${AWS_S3_BUCKET_NAME:-uploads}
-
- # SMTP (GMAIL)
- EMAIL_BACKEND: django.core.mail.backends.smtp.EmailBackend
- EMAIL_HOST: smtp.gmail.com
- EMAIL_PORT: 587
- EMAIL_USE_TLS: "1"
- EMAIL_HOST_USER: ${EMAIL_HOST_USER}
- EMAIL_HOST_PASSWORD: ${EMAIL_HOST_PASSWORD}
- DEFAULT_FROM_EMAIL: ${DEFAULT_FROM_EMAIL}Then merge *smtp-env into services that require email functionality:
environment:
- <<: [*app-env, *db-env, *redis-env, *minio-env, *aws-s3-env, *proxy-env]
+ <<: [*app-env, *db-env, *redis-env, *minio-env, *aws-s3-env, *smtp-env, *proxy-env]🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/archive/1767865532.docker-compose.yaml
around lines 27 - 34, The SMTP settings are placed in the x-aws-s3-env anchor
and contain hardcoded Gmail values; extract these into a new reusable anchor
named x-smtp-env with environment-variable placeholders for EMAIL_BACKEND,
EMAIL_HOST, EMAIL_PORT, EMAIL_USE_TLS, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, and
DEFAULT_FROM_EMAIL, remove the SMTP keys from x-aws-s3-env, and update any
services that need email to include the new anchor by merging *smtp-env into
their environment sections so providers can be swapped via env vars without
editing the compose file.
| EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend | ||
|
|
||
| EMAIL_HOST=smtp.gmail.com | ||
| EMAIL_PORT=587 | ||
| EMAIL_USE_TLS=1 | ||
|
|
||
| EMAIL_HOST_USER=[email protected] | ||
| EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh | ||
|
|
||
| DEFAULT_FROM_EMAIL="Plane <[email protected]>" | ||
|
|
There was a problem hiding this comment.
CRITICAL: Exposed SMTP credentials in version control.
Real Gmail credentials are hardcoded in this file:
[email protected]EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh(appears to be a valid Gmail app password)
This is a severe security vulnerability. These credentials are now exposed in version control and in the public GitHub repository.
Immediate actions required:
- Revoke the Gmail app password immediately
- Remove these credentials from the file and use environment variable placeholders instead
- Consider removing this file from git history using tools like
git filter-branchor BFG Repo-Cleaner - Review if the email account was compromised
Recommended fix:
-[email protected]
-EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh
+EMAIL_HOST_USER=${EMAIL_HOST_USER}
+EMAIL_HOST_PASSWORD=${EMAIL_HOST_PASSWORD}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/archive/1767865532.env around lines 46 -
56, Remove the hardcoded Gmail credentials by replacing the literal values for
EMAIL_HOST_USER and EMAIL_HOST_PASSWORD with environment variable placeholders
(e.g., EMAIL_HOST_USER=${EMAIL_HOST_USER} and
EMAIL_HOST_PASSWORD=${EMAIL_HOST_PASSWORD}) and change DEFAULT_FROM_EMAIL to
reference the same env var or a separate DEFAULT_FROM_EMAIL placeholder; add the
actual .env file to .gitignore, add a sanitized .env.example with placeholder
values and instructions, and after making these changes immediately
rotate/revoke the exposed Gmail app password and document the credential
rotation; lastly, purge the secret from git history (e.g., BFG or git
filter-branch) and notify the security/owner to validate account compromise.
|
|
||
|
|
||
| # Secret Key | ||
| SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5 |
There was a problem hiding this comment.
Hardcoded SECRET_KEY must be rotated.
The SECRET_KEY is hardcoded in this file. If this value has been used in any deployed environment, it should be rotated immediately as it's now exposed in version control. Django's SECRET_KEY is used for:
- Session signing
- CSRF token generation
- Cryptographic signing
Recommended fix:
-SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5
+SECRET_KEY=${SECRET_KEY}And provide the actual secret via environment variables at runtime.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5 | |
| SECRET_KEY=${SECRET_KEY} |
🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 73-73: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/archive/1767865532.env at line 73,
Remove the hardcoded SECRET_KEY entry and stop committing secrets to repo;
rotate the exposed SECRET_KEY immediately if it was used in any deployed
environment, then update your Django configuration (e.g., the module that
currently assigns SECRET_KEY) to read the secret from the environment at runtime
(os.environ or a secrets manager) and ensure the env var name remains SECRET_KEY
(or another agreed name) so deployments inject it securely; also add the env
file to .gitignore and update docs/CI to use secure secret provisioning.
| POSTGRES_USER: ${POSTGRES_USER:-plane} | ||
| POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-plane} |
There was a problem hiding this comment.
Weak default credentials in fallback values.
Multiple services use weak default credentials:
- Database:
POSTGRES_USER: ${POSTGRES_USER:-plane},POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-plane} - MinIO:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID:-access-key},AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY:-secret-key} - SECRET_KEY:
${SECRET_KEY:-60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5} - LIVE_SERVER_SECRET_KEY:
${LIVE_SERVER_SECRET_KEY:-2FiJk1U2aiVPEQtzLehYGlTSnTnrs7LW}
While using environment variables with fallbacks is the correct approach, ensure that:
- These defaults are only used in local development
- Production/staging deployments override all credentials via environment variables
- Documentation clearly warns against using default values
Consider adding comments to emphasize that defaults are insecure:
SECRET_KEY: ${SECRET_KEY:-60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5} # WARNING: Change for productionAlso applies to: 16-17, 21-22, 56-57, 60-60
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/docker-compose.yaml around lines 4 - 5,
The compose file currently supplies weak fallback credentials (POSTGRES_USER,
POSTGRES_PASSWORD, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SECRET_KEY,
LIVE_SERVER_SECRET_KEY); remove or restrict these insecure defaults by making
them development-only (e.g., load defaults from a separate .env.dev or wrap in a
conditional for local compose), require explicit environment values for
production (no fallbacks) and/or fail fast if missing, and add inline comments
next to each variable (for example by editing entries referencing POSTGRES_USER,
POSTGRES_PASSWORD, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SECRET_KEY,
LIVE_SERVER_SECRET_KEY) warning that the default is insecure and must be
overridden in staging/production and documented in deployment docs.
| APP_DOMAIN=localhost | ||
| APP_RELEASE=v1.2.1 | ||
|
|
||
| WEB_REPLICAS=1 | ||
| SPACE_REPLICAS=1 | ||
| ADMIN_REPLICAS=1 | ||
| API_REPLICAS=1 | ||
| WORKER_REPLICAS=1 | ||
| BEAT_WORKER_REPLICAS=1 | ||
| LIVE_REPLICAS=1 | ||
|
|
||
| LISTEN_HTTP_PORT=80 | ||
| LISTEN_HTTPS_PORT=443 | ||
|
|
||
| WEB_URL=http://${APP_DOMAIN} | ||
| DEBUG=0 | ||
| CORS_ALLOWED_ORIGINS=http://${APP_DOMAIN} | ||
| API_BASE_URL=http://api:8000 | ||
|
|
||
| #DB SETTINGS | ||
| PGHOST=host.docker.internal | ||
| PGDATABASE=plane | ||
| POSTGRES_USER=postgres | ||
| POSTGRES_PASSWORD=root | ||
| POSTGRES_DB=plane | ||
| POSTGRES_PORT=5432 | ||
| PGDATA=/var/lib/postgresql/data | ||
| DATABASE_URL=postgres://postgres:[email protected]:5432/plane | ||
|
|
||
| # REDIS SETTINGS | ||
| REDIS_HOST=host.docker.internal | ||
| REDIS_PORT=6379 | ||
| REDIS_URL=redis://host.docker.internal:6379/0 | ||
|
|
||
| # RabbitMQ Settings | ||
| RABBITMQ_HOST=host.docker.internal | ||
| RABBITMQ_PORT=5672 | ||
| RABBITMQ_USER=plane | ||
| RABBITMQ_PASSWORD=plane | ||
| RABBITMQ_VHOST=plane | ||
| AMQP_URL= | ||
|
|
||
| # ========================= | ||
| # SMTP SETTINGS (GMAIL) | ||
| # ========================= | ||
| EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend | ||
|
|
||
| EMAIL_HOST=smtp.gmail.com | ||
| EMAIL_PORT=587 | ||
| EMAIL_USE_TLS=1 | ||
|
|
||
| EMAIL_HOST_USER=[email protected] | ||
| EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh | ||
|
|
||
| DEFAULT_FROM_EMAIL="Plane <[email protected]>" | ||
|
|
||
| # If SSL Cert to be generated, set CERT_EMAIl="email <EMAIL_ADDRESS>" | ||
| CERT_ACME_CA=https://acme-v02.api.letsencrypt.org/directory | ||
| TRUSTED_PROXIES=0.0.0.0/0 | ||
| SITE_ADDRESS=:80 | ||
| CERT_EMAIL= | ||
|
|
||
|
|
||
|
|
||
| # For DNS Challenge based certificate generation, set the CERT_ACME_DNS, CERT_EMAIL | ||
| # CERT_ACME_DNS="acme_dns <CERT_DNS_PROVIDER> <CERT_DNS_PROVIDER_API_KEY>" | ||
| CERT_ACME_DNS= | ||
|
|
||
|
|
||
| # Secret Key | ||
| SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5 | ||
|
|
||
| # DATA STORE SETTINGS | ||
| USE_MINIO=1 | ||
| AWS_REGION= | ||
| AWS_ACCESS_KEY_ID=minioadmin | ||
| AWS_SECRET_ACCESS_KEY=minioadmin | ||
| AWS_S3_ENDPOINT_URL=http://host.docker.internal:9000 | ||
| AWS_S3_BUCKET_NAME=uploads | ||
| FILE_SIZE_LIMIT=5242880 | ||
|
|
||
| # Gunicorn Workers | ||
| GUNICORN_WORKERS=1 | ||
|
|
||
| # UNCOMMENT `DOCKER_PLATFORM` IF YOU ARE ON `ARM64` AND DOCKER IMAGE IS NOT AVAILABLE FOR RESPECTIVE `APP_RELEASE` | ||
| # DOCKER_PLATFORM=linux/amd64 | ||
|
|
||
| # Force HTTPS for handling SSL Termination | ||
| MINIO_ENDPOINT_SSL=0 | ||
|
|
||
| # API key rate limit | ||
| API_KEY_RATE_LIMIT=60/minute | ||
|
|
||
| # Live server environment variables | ||
| # WARNING: You must set a secure value for LIVE_SERVER_SECRET_KEY in production environments. | ||
| LIVE_SERVER_SECRET_KEY= | ||
| DOCKERHUB_USER=artifacts.plane.so/makeplane | ||
| PULL_POLICY=if_not_present | ||
| CUSTOM_BUILD=false |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
These environment files should not be committed to version control.
Both plane.env and plane.env.bak contain deployment-specific configurations and should be excluded from version control.
Recommended approach:
-
Move these files to
.gitignore:deployments/cli/community/plane-app/plane.env deployments/cli/community/plane-app/plane.env.bak
-
Create a template file instead:
# Create plane.env.example with placeholder values cp plane.env plane.env.example # Update with placeholder values as suggested in other comments
-
Document setup process:
Add instructions in the README or setup documentation:## Setup 1. Copy `plane.env.example` to `plane.env` 2. Update all placeholder values with your configuration 3. Never commit `plane.env` to version control
This follows the standard practice of keeping environment-specific configurations out of version control while providing clear templates for users.
🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 71-71: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/plane.env around lines 1 - 99, Commit
contains sensitive deployment env files (plane.env and plane.env.bak); remove
them from VCS and provide a safe template and docs. Add plane.env and
plane.env.bak to .gitignore, remove the committed secrets from the repo history
(e.g., git rm --cached and rewrite history if necessary), create a sanitized
plane.env.example with placeholder values copied from plane.env (redact real
secrets like SECRET_KEY, EMAIL_HOST_PASSWORD, AWS_SECRET_ACCESS_KEY,
LIVE_SERVER_SECRET_KEY, DATABASE_URL, REDIS_URL, AMQP_URL), and update
README/setup docs with steps to copy plane.env.example to plane.env and never
commit it.
| PGHOST=host.docker.internal | ||
| PGDATABASE=plane | ||
| POSTGRES_USER=postgres | ||
| POSTGRES_PASSWORD=root |
There was a problem hiding this comment.
Weak default database password.
Using root as the default PostgreSQL password is insecure, especially if this configuration is used as a template for production deployments.
🔒 Recommended fix
-POSTGRES_PASSWORD=root
+POSTGRES_PASSWORD=change-me-to-a-strong-passwordAdd a comment encouraging users to generate strong passwords:
+# Generate a strong password: openssl rand -base64 32
POSTGRES_PASSWORD=change-me-to-a-strong-password📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| POSTGRES_PASSWORD=root | |
| # Generate a strong password: openssl rand -base64 32 | |
| POSTGRES_PASSWORD=change-me-to-a-strong-password |
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/plane.env.bak at line 24, The
POSTGRES_PASSWORD entry currently uses a weak hardcoded value
("POSTGRES_PASSWORD=root"); replace this with a placeholder and guidance—e.g.,
change to a non-sensitive placeholder (like
POSTGRES_PASSWORD=__GENERATE_STRONG_PASSWORD__) and add a single-line comment
above or next to the POSTGRES_PASSWORD key recommending users generate a strong,
unique password (and/or use a secrets manager) before deploying; ensure the
symbol POSTGRES_PASSWORD is updated accordingly wherever the env file is
consumed.
| [email protected] | ||
| EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh |
There was a problem hiding this comment.
CRITICAL: Real email credentials exposed in version control.
The file contains actual Gmail credentials ([email protected] with an app-specific password). Committing real credentials to version control is a critical security vulnerability that can lead to:
- Unauthorized access to the email account
- Potential data breaches
- Compliance violations
🔒 Recommended fix
Replace with placeholder values and document that users must provide their own credentials:
-[email protected]
-EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh
+[email protected]
+EMAIL_HOST_PASSWORD=your-app-specific-passwordRequired actions:
- Remove these credentials from version control history using tools like
git-filter-repoor BFG Repo-Cleaner - Revoke the exposed Gmail app password immediately at https://myaccount.google.com/apppasswords
- Add
plane.envandplane.env.bakto.gitignore - Provide a
plane.env.examplefile with placeholder values instead
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| EMAIL_HOST_USER=saifurrahman.dev.ai@gmail.com | |
| EMAIL_HOST_PASSWORD=gdkbknshfszmtxlh | |
| EMAIL_HOST_USER=your-email@example.com | |
| EMAIL_HOST_PASSWORD=your-app-specific-password |
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/plane.env.bak around lines 52 - 53, The
commit exposes real credentials in the environment backup—replace the values of
EMAIL_HOST_USER and EMAIL_HOST_PASSWORD with placeholders (e.g.
[email protected] and EMAIL_HOST_PASSWORD=REPLACE_ME), add
plane.env and plane.env.bak to .gitignore, create a plane.env.example with
placeholder values and documentation, revoke the exposed Gmail app password
immediately, and remove the secrets from repository history using
git-filter-repo or BFG Repo-Cleaner to purge EMAIL_HOST_USER/EMAIL_HOST_PASSWORD
from past commits.
|
|
||
|
|
||
| # Secret Key | ||
| SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5 |
There was a problem hiding this comment.
CRITICAL: Hardcoded SECRET_KEY must be removed.
The Django SECRET_KEY is hardcoded in version control, which is a critical security issue. This key is used for cryptographic signing and should be unique per deployment.
🔒 Recommended fix
-SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5
+SECRET_KEY=change-me-to-a-random-50-character-stringRequired actions:
- Generate unique SECRET_KEY values for each environment using:
python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())' - Store production keys in secure secret management systems (e.g., AWS Secrets Manager, HashiCorp Vault)
- Never commit real SECRET_KEY values to version control
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5 | |
| SECRET_KEY=change-me-to-a-random-50-character-string |
🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 73-73: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/plane.env.bak at line 73, Hardcoded
SECRET_KEY exposed in the repo (the SECRET_KEY line) must be removed; replace
the hardcoded value with reading from an environment variable (e.g.,
DJANGO_SECRET_KEY) and fail fast if missing, rotate the current key, remove the
SECRET_KEY entry from version control, and move the new per-environment keys
into a secrets manager (AWS Secrets Manager/HashiCorp Vault) so deployments load
the key from secure storage rather than from the file.
| AWS_S3_ENDPOINT_URL=http://host.docker.internal:9000 | ||
| AWS_S3_BUCKET_NAME=uploads | ||
| FILE_SIZE_LIMIT=5242880 | ||
| MINIO_ENDPOINT_SSL=0 |
There was a problem hiding this comment.
Remove duplicate MINIO_ENDPOINT_SSL setting.
MINIO_ENDPOINT_SSL=0 appears twice (lines 82 and 91), which can cause confusion.
♻️ Proposed fix
FILE_SIZE_LIMIT=5242880
-MINIO_ENDPOINT_SSL=0
# Gunicorn Workers
GUNICORN_WORKERS=1Also applies to: 91-91
🤖 Prompt for AI Agents
In @deployments/cli/community/plane-app/plane.env.bak at line 82, The env file
contains a duplicate setting for MINIO_ENDPOINT_SSL; remove the redundant entry
so only a single MINIO_ENDPOINT_SSL assignment remains (keep the intended value
and delete the other occurrence), ensuring no duplicate environment keys exist
in the file to avoid confusion or unexpected overrides.
| SECRET_KEY=dev-secret | ||
| TRUSTED_PROXIES=0.0.0.0/0 | ||
| SITE_ADDRESS=:8080 |
There was a problem hiding this comment.
Overly permissive security settings.
SECRET_KEY=dev-secretis a placeholder that must be changed for any non-local environmentTRUSTED_PROXIES=0.0.0.0/0trusts all IPs, which could allow proxy header spoofing attacks if this configuration is accidentally used beyond localhost
Ensure these values are overridden in production deployments.
🤖 Prompt for AI Agents
In @deployments/cli/community/variables.env around lines 52 - 54, Replace the
placeholder SECRET_KEY with a strong, unique secret in non-local environments
(do not commit dev-secret), remove or narrow TRUSTED_PROXIES instead of using
0.0.0.0/0 (restrict to known proxy IPs or leave unset so defaults block
spoofing), and ensure SITE_ADDRESS is set appropriately for production; make
these values configurable via environment-specific overrides or a secret
management system so production deployments never use the dev defaults.
Description
Type of Change
Screenshots and Media (if applicable)
Test Scenarios
References
Note
Introduces community deployment configs for Plane and switches local defaults to a host-based setup.
deployments/cli/community/plane-app/docker-compose.yamldefining full service stack (web,space,admin,live,api,worker,beat-worker,migrator,plane-db,plane-redis,plane-mq,plane-minio,proxy) with shared env anchorsplane.env, backups, and archived variants including SMTP (Gmail) and S3/MinIO settingsdeployments/cli/community/variables.envto127.0.0.1host services, port8080,DEBUG=1, explicitDATABASE_URL,REDIS_URL,AMQP_URL,SITE_ADDRESS, andSECRET_KEY; addsvariables.env.savesnapshotWritten by Cursor Bugbot for commit de767c9. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.