ops: define paid-app service in docker-compose.prod.yml#24
Conversation
|
Warning Review limit reached
More reviews will be available in 56 minutes and 20 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
Greptile SummaryThis PR tracks the production
Confidence Score: 4/5Safe to merge after adding a profiles guard to paid-app; without it, the existing free-tier deploy script will fail on any VPS where ../komi-paid-backend has not been synced. The free-tier deploy.sh runs docker compose up -d --build with no service targets. Now that paid-app is in the compose file without a profiles key, every free-tier deploy attempts to build it from ../komi-paid-backend. On a VPS without that path, set -euo pipefail aborts the deploy mid-flight. The rest of the change is well-structured and consistent with existing services. docker-compose.prod.yml — the paid-app service block needs a profiles: [paid] key before this is safe to deploy against the shared VPS. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[deploy.sh on VPS] -->|docker compose -f docker-compose.prod.yml up -d --build| B{No service target specified}
B -->|builds ALL services| C[app free-tier]
B -->|builds ALL services| D[paid-app]
B -->|builds ALL services| E[caddy / postgres / etc]
D -->|build context| F[../komi-paid-backend]
F -->|path missing?| G[❌ Build fails — entire deploy aborted]
F -->|path exists| H[paid-app container starts]
C --> I[depends_on postgres healthy]
H --> I
I --> J[(postgres komistore_paid DB)]
style G fill:#ff6b6b,color:#fff
style D fill:#ffd93d
Reviews (2): Last reviewed commit: "Merge branch 'main' into ops/paid-app-co..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
… deploy) The paid-backend deploy script runs `docker compose ... up -d --build paid-app` against this compose file, but the paid-app service was never defined here — operators were hand-editing the service block on the VPS to make deploys work. This made the production topology untracked by git, which is exactly the kind of drift a perf audit catches. Service block: - Builds from ../komi-paid-backend (sibling deploy dir on the VPS). - Shares the existing postgres container; isolates via komistore_paid DB. - mem_limit 1.5g — tight but defensible (see comment for the 8 GB budget). - read_only rootfs + tmpfs /tmp matches the free-tier app hardening. - Env vars cover Stripe, R2, Cloudflare KV signing keys, and the internal-auth allowlist; sensible defaults so unset values fall back cleanly without breaking the boot of free-tier app. .env.example documents every new key so operator setup is self-serve.
…reptile)
Greptile flagged the silent-failure path: ${KOMI_KEY_SOURCE:-cloudflare_kv}
combined with empty defaults for CF_ACCOUNT_ID / CF_KV_NAMESPACE_ID /
CF_API_TOKEN means an operator who follows the minimum env checklist but
forgets the Cloudflare vars boots a healthy-looking container that 404s
on every signing-key fetch.
Switching the compose fallback to KEY_SOURCE=env makes the missing
configuration surface immediately as 'env var ED25519_PRIVATE_KEY not
set' — a clearly-named failure tied to the actual code path. Production
deploys (which use CF KV) just set KOMI_KEY_SOURCE=cloudflare_kv
explicitly in /opt/github-store-backend/.env. The paid-backend's
SigningConfig.from additionally fail-fasts on empty CF vars when
KEY_SOURCE=cloudflare_kv, so a half-configured CF deploy crashes at
AppConfig.from() not at signing time.
Healthcheck path stands: paid-backend serves bare /health (verified at
Application.kt:195), distinct from free-tier /v1/health.
rainxchzed
force-pushed
the
ops/paid-app-compose-service
branch
from
6d54d24 to
2a8d0f8
Compare
| paid-app: | ||
| build: ../komi-paid-backend | ||
| restart: unless-stopped |
There was a problem hiding this comment.
deploy.sh (line 26) runs docker compose -f docker-compose.prod.yml up -d --build with no service targets, so it will attempt to build paid-app from ../komi-paid-backend on every free-tier deploy. On any VPS where the paid-backend hasn't been synced (fresh rollout, separate free-tier host, etc.), the build step will fail with a "path not found" error and set -euo pipefail will abort the entire deploy — taking down the free-tier backend mid-deploy. Even on the shared VPS, paid-app gets rebuilt and restarted on every free-tier release, causing unnecessary disruption for paid users. Adding a profiles key restricts paid-app to opt-in runs (docker compose --profile paid up -d --build) and leaves the free-tier deploy unaffected.
| paid-app: | |
| build: ../komi-paid-backend | |
| restart: unless-stopped | |
| paid-app: | |
| build: ../komi-paid-backend | |
| restart: unless-stopped | |
| profiles: [paid] |
1 participant
The perf audit caught that `paid-backend/deploy.sh` runs `docker compose up -d --build paid-app` against a compose file that doesn't define a `paid-app` service. Operators have been hand-editing the block on the VPS to make deploys work — the production topology was untracked by git.
This PR moves that block into the repo so the deploy is reproducible.
Changes
Pre-merge operator steps
Populate `/opt/github-store-backend/.env` on the VPS with the new `KOMI_`, `CF_`, `STRIPE_`, and `ED25519_` keys — at minimum:
Without these, `docker compose up paid-app` will fail fast at boot with explicit env-var-missing errors (this is the AppConfig fail-fast behaviour from PR #3 on paid-backend).
Compose interaction with PR #22 (api.komistore.app vhost)
PR #22 references `paid-app:8080` in the Caddyfile. Caddy's `depends_on` block still only references `app` (free-tier) so a paid-app outage doesn't block the free-tier from starting; Caddy will return 502 for api.komistore.app traffic until paid-app is healthy.