Repository navigation
Conversation
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
The nibrun prefill omits TRUSTED_PROXY_CIDRS. nibrun's in-VM Caddy connects to the binary from 127.0.0.1, so Calnode ignores X-Forwarded-For and keys every rate limit on that one address: the 60/min slots and 20/min booking limits become deployment-wide. Add the trusted-proxy entry to the prefilled env (and the button/preset) so a busy calendar does not 429 every visitor.
Reviewed changes
- nibrun deploy section (
DEPLOY.md) — secrets, the prefilledBASE_URL/DATABASE_URL/DATA_DIRvalues, first-run owner claim, custom domains, Litestream/backup limits, and idle-suspension effects on the reminder, webhook-retry and calendar-reconciliation workers. - Deploy button (
README.md) — checksum-pinnedapp.nibrun.comlink in "Deploy for real". The URL matches nibrun'scalnodepreset exactly, and the SHA-256 matches the publishedv0.11.2amd64 asset.
deepseek-v4.1-flash ｜ 𝕏
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Reviewed the follow-up commit against the prior review, covering the two files changed since.
- Added
TRUSTED_PROXY_CIDRS=127.0.0.1to the nibrun prefill table and the README deploy button, matching nibrun'scalnodepreset, with an accurate caveat that same-edge visitors still share a bucket. - Replaced the dead-end backup pointer with concrete Export /
nib apps exportinstructions, archive contents, and restore steps, including the plaintext-credentials warning.
Both prior threads are addressed and resolved. The documented nib apps export … --app … invocation and the Caddy XFF behaviour were checked against nibrun upstream.
deepseek-v4.1-flash ｜ 𝕏
|
Closing this, and I want to be straight about why. The work is good. The checksum pin, The problem is placement, not quality. A "Deploy on nibrun" button in the project README is an endorsement of one commercial service, in the most prominent position we have. We are not doing that for a contributor's own product, because the moment it happens once every hosting provider and deploy tool will ask for the same slot, and the README stops being documentation and becomes a directory. Better not to set that precedent at all than to argue it case by case. So: no third-party deploy buttons or vendor guides in the README. That applies to everyone, not just this one. The standalone binaries from #112 stay, and DEPLOY.md already documents running them without Docker, so anyone who wants to host Calnode somewhere specific has a general path to follow. Thanks for #112. Closing this one. |
1 similar comment
|
Closing this, and I want to be straight about why. The work is good. The checksum pin, The problem is placement, not quality. A "Deploy on nibrun" button in the project README is an endorsement of one commercial service, in the most prominent position we have. We are not doing that for a contributor's own product, because the moment it happens once every hosting provider and deploy tool will ask for the same slot, and the README stops being documentation and becomes a directory. Better not to set that precedent at all than to argue it case by case. So: no third-party deploy buttons or vendor guides in the README. That applies to everyone, not just this one. The standalone binaries from #112 stay, and DEPLOY.md already documents running them without Docker, so anyone who wants to host Calnode somewhere specific has a general path to follow. Thanks for #112. Closing this one. |
Adds a checksum-pinned nibrun deploy button and setup instructions for the standalone release, so users can deploy without a local build or Docker image.
Documents secrets, persistent storage, custom domains, and the limitations around Litestream and idle suspension. Verified that the button URL matches the nibrun preset and that the new Markdown links and anchors resolve.