Docs: non-production cost optimization + Terraform/YAML guidance#347
Docs: non-production cost optimization + Terraform/YAML guidance#347justin808 wants to merge 1 commit into
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR adds documentation covering two related areas of deployment and cost management. It clarifies the complementary roles of ChangesDocumentation Additions
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| it — acceptable for non-production. | ||
|
|
||
| A managed alternative is a single small RDS instance hosting many databases; see | ||
| [migrating from Heroku Postgres to RDS](https://pelle.io/posts/hetzner-rds-postgres). |
There was a problem hiding this comment.
The link text says "Heroku Postgres" but the URL slug is hetzner-rds-postgres — this appears to be about migrating from Hetzner-hosted Postgres (self-managed VPS) to RDS, not from Heroku Postgres. The same mismatch exists in the pre-existing Useful Links entry at the bottom of the file (line 456).
| [migrating from Heroku Postgres to RDS](https://pelle.io/posts/hetzner-rds-postgres). | |
| [migrating from Hetzner Postgres to RDS](https://pelle.io/posts/hetzner-rds-postgres). |
Worth verifying the article title before merging, and fixing the Useful Links entry at the same time for consistency.
Greptile SummaryThis PR adds two docs-only sections: a "Right-Sizing Non-Production Workloads" guide in
Confidence Score: 4/5Docs-only change with no source code modifications; safe to merge after addressing the link-text mismatch. The new content is accurate and well-structured. The only issues are a link text that says "AWS RDS" while the URL points to a Hetzner article (which would send readers to the wrong tutorial) and a YAML snippet missing its workload-level fields for consistency. docs/tips.md — review the RDS link text and the incomplete autoscaling YAML snippet. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[New environment needed?] --> B{Environment type}
B --> |Ephemeral / PR review| C[cpflow YAML + cpflow deploy]
B --> |Long-lived: staging/production| D[cpflow terraform generate]
C --> E[Dynamic per-PR app names]
C --> F[cleanup-stale-apps / ps:stop / ps:start]
C --> G[No Terraform state to manage]
D --> H[terraform apply]
H --> I[Tracked state file + drift detection]
H --> J[terraform plan surfaces config drift]
D --> K[YAML templates remain source of truth]
K --> |Templates change| D
Reviews (1): Last reviewed commit: "Add non-production cost-optimization tip..." | Re-trigger Greptile |
Review: Docs — Non-Production Cost Optimization + Terraform/YAML GuidanceOverall: Approve with one factual fix needed. This is a well-written, genuinely useful addition. The content is accurate, the YAML examples are correct, and the cross-linking between the two files is clean. What the PR does
IssuesBug — one factual error (inline comment posted): Minor observations (non-blocking)
VerdictThe documentation is accurate, well-structured, and fills a real gap. One factual fix (Heroku → Hetzner in the link text) is required; the rest are suggestions. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| A managed alternative is a single small RDS instance hosting many databases; see | ||
| [migrating from Heroku Postgres to RDS](https://pelle.io/posts/hetzner-rds-postgres). | ||
|
|
There was a problem hiding this comment.
The link text says "migrating from Heroku Postgres to RDS" (implying AWS RDS), but the URL is https://pelle.io/posts/hetzner-rds-postgres — Hetzner and AWS RDS are different managed-database products with distinct setup steps. A reader following the "RDS" framing and clicking through would land on a Hetzner tutorial, which could cause confusion when the infrastructure details don't match.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| ```yaml | ||
| spec: | ||
| defaultOptions: | ||
| capacityAI: true | ||
| autoscaling: | ||
| metric: disabled | ||
| minScale: 1 | ||
| maxScale: 1 | ||
| ``` |
There was a problem hiding this comment.
kind: and name: top-level fields that are present in every other YAML snippet in this section (e.g. the Capacity AI snippet directly above and the Postgres snippet below). Without those fields the snippet looks like an incomplete fragment and readers can't tell which workload it applies to.
| ```yaml | |
| spec: | |
| defaultOptions: | |
| capacityAI: true | |
| autoscaling: | |
| metric: disabled | |
| minScale: 1 | |
| maxScale: 1 | |
| ``` | |
| ```yaml | |
| kind: workload | |
| name: rails | |
| spec: | |
| defaultOptions: | |
| capacityAI: true | |
| autoscaling: | |
| metric: disabled | |
| minScale: 1 | |
| maxScale: 1 |
Document how to reduce Control Plane spend on long-lived non-production environments (staging, demos) and clarify that Terraform complements the cpflow YAML workflow rather than replacing it. docs/tips.md: new "Right-Sizing Non-Production Workloads" section -- enable Capacity AI on idle workloads, disable CPU autoscaling for idle apps, right-size reserved CPU/memory (e.g. avoid pinning Postgres at a full core), drop unused workers (run Solid Queue in Puma), share one Postgres across non-production apps, and keep templates as the source of truth to avoid console drift. docs/terraform/overview.md: new "Terraform and cpflow Are Complementary" section -- cpflow deploy for ephemeral review apps, generated Terraform for long-lived staging/production with state tracking and drift detection. Docs-only; no source-code changes, so no CHANGELOG entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
justin808
force-pushed
the
jg/non-prod-cost-optimization-docs
branch
from
a670c5b to
599cb21
Compare
coderabbitai
Bot
added
documentation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Code Review: Docs — Non-Production Cost Optimization + Terraform/YAML GuidanceOverall: This is a well-written, practical addition to the guide. The content is accurate, the tradeoffs are honestly stated, and the new section slots cleanly into the existing tips structure. All cross-link anchors verified. A few minor issues worth addressing before merge: Correctness
Style / Consistency
Clarity
The |
| defaultOptions: | ||
| capacityAI: true | ||
| autoscaling: | ||
| metric: disabled |
There was a problem hiding this comment.
The spec files in this repo quote this value as "disabled" — e.g. generator_spec.rb:522 and workload_spec.rb:172. YAML parses an unquoted disabled as a string too, but quoting it matches the established convention and avoids any surprises with strict YAML validators.
| metric: disabled | |
| metric: "disabled" |
| app multiplies standing cost. For non-production, several apps can share a single Postgres | ||
| server, each using its own database: | ||
|
|
||
| - Point each app's `DATABASE_HOST` (in `templates/app.yml`) at the shared instance's |
There was a problem hiding this comment.
templates/app.yml isn't a standard cpflow filename — the canonical location is .controlplane/templates/ and the actual file name varies per app (e.g. rails.yml, app.yml depends on what the user named it). A more accurate phrasing:
| - Point each app's `DATABASE_HOST` (in `templates/app.yml`) at the shared instance's | |
| - Point each app's `DATABASE_HOST` environment variable (in `.controlplane/templates/`) at the shared instance's |
| ```yaml | ||
| spec: | ||
| defaultOptions: | ||
| capacityAI: true | ||
| autoscaling: | ||
| metric: disabled | ||
| minScale: 1 | ||
| maxScale: 1 | ||
| ``` |
There was a problem hiding this comment.
This snippet starts at spec: while the Capacity AI snippet above begins with kind:/name:. Readers copy-pasting this fragment directly into a template would get a headless YAML block. Consider either adding the header to match the first snippet, or adding a note like # (partial — add to your workload's spec.defaultOptions) to signal it's an excerpt.
| - Expose the database port at **exactly one** level (org *or* GVC, never both) to avoid | ||
| Control Plane routing conflicts. |
There was a problem hiding this comment.
This is the most operationally risky advice in the section but the least explained. Readers unfamiliar with Control Plane's networking model won't know what "expose at org level" vs "GVC level" means, or what the routing conflict looks like in practice. A one-sentence clarifier (or a link to the relevant Control Plane docs on port/service exposure) would significantly reduce the chance of misconfiguration.
1 participant
Summary
Adds user-facing documentation on two related topics that currently have no home in the guide:
Changes
docs/tips.md— new section "Right-Sizing Non-Production Workloads":SOLID_QUEUE_IN_PUMA=true) instead of a full-time workercpflow deploy; bridges to Terraform drift detectiondocs/terraform/overview.md— new section "Terraform andcpflowAre Complementary":cpflow deployfor ephemeral review apps; generated Terraform for long-lived staging/productioncpflow terraform generatekeeps the YAML templates as the single source of truth, and thatterraform plansurfaces driftNotes
controlplaneflow-comon merge (perCONTRIBUTING.md).🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes with no runtime, auth, or infrastructure code impact.
Overview
Docs-only: expands the user guide with non-production cost levers and clarifies how Terraform fits alongside
cpflowdeploy.docs/tips.mdadds Right-Sizing Non-Production Workloads for long-lived staging/demo apps (beyond the existing review-app section): Capacity AI, turning off CPU autoscaling on idle apps, lowering reserved CPU/memory (especially Postgres), dropping unused workers (e.g. Solid Queue in Puma), sharing one Postgres across apps, and keeping.controlplane/templates/as the source of truth—with a link to Terraform for drift on stable envs.docs/terraform/overview.mdadds Terraform andcpflowAre Complementary: review apps stay oncpflow deploy; staging/production use generated Terraform from the same templates, withterraform planfor drift—cross-linked to the new tips section.Reviewed by Cursor Bugbot for commit 599cb21. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit
cpflow deployfor ephemeral environments, generated Terraform for stable long-lived environments with state tracking and drift detection.