docs(deploy): demote render.yaml to a reference manifest and fix TLS prose#258
Merged
Conversation
…prose The deployment docs described a service that does not exist. Three fixes, all now verified against the live API. render.yaml is applied to nothing. No Blueprint is registered on the account and the service predates the file, so nothing syncs it; the TLS_PORT mismatch (8443 in the file, 4443 live) is the proof — a syncing Blueprint could not leave those different. Calling the file "versioned" implied a source-of-truth relationship that has never existed, and an operator who believed it would edit the file and wonder why production ignored them. It is now documented as a reference manifest, with the dashboard named as the source of truth for environment variables. The service *shape* genuinely does match the file, so that is stated explicitly rather than left ambiguous. Align the manifest with the live service: add TLS_ENABLED=false (undeclared, though it drives the whole TLS posture) and drop TLS_PORT, which was both dead and contradicted. TLS_KEY/TLS_CERT are dropped now that the conditional validation fix is live and healthy in production, so they are no longer needed to boot. They remain set on the dashboard until they are retired there. Fix the TLS prose. PORT is pinned explicitly to 8080 on the dashboard, not injected by Render as claimed, so an operator sizing a second service would have drawn the wrong conclusion. The certificate statements are now accurate post-fix and say so precisely: when TLS is disabled the credentials are neither required nor loaded, rather than merely "not loaded".
renderConfig.test.js asserted that TLS_KEY and TLS_CERT were declared in render.yaml with `sync: false`, which encoded the old belief that production depends on them. It does not: TLS terminates at the edge, the app never loads the certificates, and the validator no longer requires them to boot. Update the test to the contract the manifest now describes — REPLICATE_API_TOKEN stays the only secret-bearing entry — and add coverage for what the removal means, so a future edit cannot quietly reintroduce credentials the service never reads or resurrect the TLS_PORT value that never matched production. Quote TLS_ENABLED's value. Bare `false` is a YAML boolean, while config/index.js keys off the string 'false'; the quoted form says what is meant and the new assertion holds it there.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows #257, which had to be live before the manifest could drop the
certificate entries. It is: deploy
dep-d9bjcdcvikkc73e42vjgis live onb5fca356cand/api/healthreturns200 {"ready":true}.render.yamlis applied to nothingDEVELOPMENT.mdsaid the service shape was "versioned inrender.yaml".It is not:
The empty Blueprint list and the
TLS_PORTmismatch are jointly conclusive —if anything were syncing,
TLS_PORTcould not differ. The service isdashboard-managed. The file now says so, and names the dashboard as the source
of truth for environment variables.
The service shape does match the file exactly (plan, region, instances,
health check, build, start, runtime, branch, auto-deploy), so that is now
stated rather than left ambiguous. No Blueprint is registered by this PR, and
none should be: a sync would reset
TLS_PORTto 8443 and could strip theprovider credentials the service actually runs on.
Manifest vs. live
Added
TLS_ENABLED=false— it drives the entire TLS posture and wasundeclared. Removed
TLS_PORT— dead (TLS is off) and contradicted.Removed
TLS_KEY/TLS_CERT, which is safe only now that #257 is live: theservice no longer needs them to boot. They are still set on the dashboard;
retiring them there is a separate step.
TLS prose
PORTis pinned to8080on the dashboard, not injected by Render. The docclaimed injected. Anyone standing up a second service from this document would
have inherited a wrong assumption, so the doc now matches the dashboard.
The certificate statements were false when the audit was written and are true
now that #257 is live — they are kept and sharpened rather than rewritten:
when TLS is disabled the credentials are neither required nor loaded, where
the doc previously said only "not loaded", which was the exact ambiguity that
made removing them look safe when it was not.
Verification
render.yamlparses and resolves toTLS_ENABLED=falsewith noTLS_PORT,TLS_KEYorTLS_CERT.docs:validatepasses. The#inbound-tls-posture-...anchor still resolves. No live configuration istouched by this PR.