RFC 0023: Standard Hosting Profiles

[giodl73-repo]

Decision Requested

Should OpenClaw ship a small catalog of named, release-tested hosting postures over the readiness facility proposed in RFC 0018? Readiness remains independently useful without a profile.

Why

OpenClaw runs locally, in containers, behind identity proxies, and as a controller for paired execution targets, but those labels are not reproducible support contracts. Their intent is scattered across startup flags, environment, config, probes, and private checklists. A release cannot exercise or support the posture as one coherent packaged scenario.

Proposed V1

Profiles are optional compositions of RFC 0018 criteria, not another evaluator.

Profile	Supported posture	Profile-specific evidence
local	Foreground/local Gateway	Shared serving baseline
container	Directly reachable container listener	Non-loopback effective listener
reverse-proxy	Gateway behind a trusted identity proxy	Trusted-proxy auth, identity header, trusted source, and viable topology
node-mode	Gateway controlling execution targets	Approved pairing, connected target, command-policy approval, and live control channel

Every profile selects the same required serving baseline and advisory operational facts. Selection precedence is gateway argument > environment > openclaw.json; unprofiled startup remains unchanged, and operators can add criteria directly.

This PR includes the normative Standard Hosting Profile v1 sidecar.

Support And Identity Contract

A profile provides a reproducible support subset: OpenClaw names the posture, reports its unmet conditions, attributes them to RFC 0018 identities that renew with their owner lifecycles, and executes matching packaged scenarios.

Docker, Kubernetes, systemd, OCC, and downstream hosts continue to consume ordinary /readyz. Profiles observe effective state; they do not generate or repair config, add Lobster/OCC resources, encode scheduler policy, or initiate subsystems.

Operator Facilities

OpenClaw PR 114636 combines catalog inspection, live validation, and package release evidence as one ordered upstream review unit at exact head 123bae7b876.

Implementation Stack

RFC 0023 builds on RFC 0018, so its complete upstream landing order is:

1. PR 104018 provides the readiness framework and subject identity at exact head 2f131c6e220.
2. PR 113421 provides reusable core-owner conditions at exact head c1d7f394f86.
3. PR 113422 directly implements the four Standard Hosting Profiles and package scenario matrix at exact head 18c42a7f26a.
4. PR 114636 directly implements profile inspection, live validation, and package release-conformance evidence at exact head 123bae7b876.

The integrated tree passes 120 focused assertions plus formatting, lint, shell syntax, and diff checks. Exact-head package-installed Docker proof passes all 13 states on GitHub-hosted Actions, independently verifies the artifact, and uploads it as release evidence.

Deliberate V1 Boundary

This RFC does not promise custom profile inheritance, host assertions, signed attestations, config generation/repair, scheduler policy, or Lobster/OCC resources. The conformance artifact is portable release evidence, not an immutable or signed attestation.

Promotion Order

1. Accept RFC 0018 and PR 104018 independently.
2. Land reusable owner observations in PR 113421.
3. Decide whether the four named postures are the right initial support catalog.
4. Land PR 113422 with its package-installed profile matrix.
5. Land catalog inspection, live validation, and the release-conformance artifact as separable operator/release facilities.

[giodl73-repo]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review published an exact durable review comment and queued an executing target-wide serialized router scan.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29405019138
• Updated: 2026-07-15T10:29:21.908Z

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 27, 2026, 6:36 PM ET / 22:36 UTC.

ClawSweeper review

What this changes

This PR adds RFC 0023 and a companion v1 specification defining four opt-in OpenClaw hosting profiles—local, container, reverse-proxy, and node-mode—over the proposed readiness system.

Merge readiness

⚠️ Ready for maintainer review - 5 items remain

Keep this RFC open for maintainer product-direction review. It proposes a new, compatibility-sensitive support contract rather than documenting an already accepted or implemented behavior, and its required readiness foundation remains an open RFC. Likely related person: giodl73-repo (medium confidence), based on authorship of this RFC and the companion readiness RFC.

Priority: P3
Reviewed head: e931e8d95e157b3f1abd38c906a4e31a5c1d345d
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The documentation is substantial and coherent, but its merge readiness depends on an unresolved maintainer decision about the proposed product and compatibility contract.
Proof confidence	🌊 off-meta tidepool	Not applicable: This PR changes only RFC documentation files, so runtime proof is not a merge gate; the linked package-installed evidence remains useful context for any later OpenClaw implementation review.
Patch quality	🦐 gold shrimp (3/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This PR changes only RFC documentation files, so runtime proof is not a merge gate; the linked package-installed evidence remains useful context for any later OpenClaw implementation review.
Evidence reviewed	5 items	Proposed RFC surface: The branch adds two new RFC Markdown documents totaling 966 lines: the RFC and an implementation-facing profile specification. The documents define a new v1 catalog and contract rather than a correction to current repository documentation. Compatibility contract is explicit: The specification states that profile IDs, predicates, required criteria, and stable reasons are contracts; it also defines opt-in selection precedence and startup validation for an invalid explicit profile. Those are product and upgrade commitments requiring maintainer approval. Dependency is unresolved: The PR body and RFC identify RFC 0018 as the owner of the readiness evaluator and condition model, while the supplied related-item context shows RFC 0018 is still open at #33. This RFC therefore cannot be treated as documentation for an already-settled core contract.
Findings	None	None.
Security	None	None.

How this fits together

Standard Hosting Profiles sit above Gateway readiness: configuration or startup selection chooses a named deployment posture, which composes readiness conditions and exposes a supportable readiness result. The proposed contracts would affect startup validation, /readyz interpretation, operator support expectations, and release-conformance scenarios.

flowchart LR
  A[Operator config or startup argument] --> B[Profile selection]
  B --> C[Named hosting profile]
  C --> D[Readiness conditions]
  D --> E[Gateway readiness result]
  E --> F[Operator status and ready endpoint]
  C --> G[Release conformance scenarios]

Loading

Decision needed

Question	Recommendation
Should OpenClaw adopt local, container, reverse-proxy, and node-mode as the initial named, release-tested hosting support catalog once the readiness contract is accepted?	Accept the bounded v1 catalog: Approve the four opt-in profiles as the initial support contract, while preserving unprofiled readiness behavior and sequencing implementation after RFC 0018.

Why: This PR intentionally introduces new product terminology, startup-selection behavior, compatibility commitments, and supported deployment boundaries; no source-level check can determine whether those are the support postures OpenClaw should permanently promise.

Before merge

• Add real behavior proof - Not applicable: This PR changes only RFC documentation files, so runtime proof is not a merge gate; the linked package-installed evidence remains useful context for any later OpenClaw implementation review.
• Resolve merge risk (P1) - Accepting this RFC would make the four profile names, predicates, selection precedence, stable reasons, and invalid-profile startup behavior a compatibility-facing contract before the prerequisite readiness RFC and cited implementation PR are merged.
• Resolve merge risk (P1) - The proposed reverse-proxy and node-mode support postures define security- and topology-adjacent expectations, so their exact boundaries need maintainer ownership rather than inference from an RFC-only change.
• Complete next step (P2) - A maintainer must choose whether this new hosting-profile and configuration contract belongs in the supported product before any implementation or RFC acceptance can proceed.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
RFC design surface	2 added files; 966 lines added	The PR creates both a policy RFC and a normative sidecar, so approval establishes a broad contract rather than making a small documentation correction.
Referenced implementation stack	4 upstream implementation PRs named	The proposal depends on a staged upstream path, including an implementation PR that remains open in the supplied context.

Merge-risk options

Maintainer options:

1. Approve with explicit compatibility ownership (recommended)
   Accept the RFC only after a maintainer confirms that the named profile IDs, selection rules, and stable non-ready reasons are intended public support contracts.
2. Defer the catalog decision
   Keep the readiness foundation separate and pause this RFC until maintainers choose which deployment postures OpenClaw will support and release-test.

Technical review

Best possible solution:

Have a maintainer explicitly decide whether the four opt-in postures are the intended initial support catalog after the readiness contract is accepted; if approved, keep the RFC bounded to that catalog and land runtime work only through the linked upstream implementation sequence.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is an RFC-only proposal, not a report of broken current behavior. The changed files define future contracts and do not provide a current-main failure path to reproduce.

Is this the best way to solve the issue?

Unclear: the opt-in boundary and separation from readiness are coherent, but deciding that these exact four profiles should become OpenClaw support contracts requires maintainer product judgment before this is the best solution.

AGENTS.md: unclear because the file could not be read completely.

Codex review notes: model internal, reasoning high; reviewed against 593e6e46632b.

Labels

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

• P3: This is a speculative, optional product-support catalog requiring design approval rather than an urgent user-facing regression.
• merge-risk: 🚨 compatibility: The RFC proposes persistent profile identifiers, configuration precedence, startup validation, predicates, and stable reasons that existing operators may rely on after adoption.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• feature: ✨ showcase: ClawSweeper spotlight: unusually compelling feature idea for maintainer attention. The proposal turns broad hosting claims into a small, explicit, release-testable support catalog while preserving an unprofiled compatibility path.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This PR changes only RFC documentation files, so runtime proof is not a merge gate; the linked package-installed evidence remains useful context for any later OpenClaw implementation review.

Evidence

What I checked:

• Proposed RFC surface: The branch adds two new RFC Markdown documents totaling 966 lines: the RFC and an implementation-facing profile specification. The documents define a new v1 catalog and contract rather than a correction to current repository documentation. (rfcs/0023-standard-hosting-profiles.md:1, e931e8d95e15)
• Compatibility contract is explicit: The specification states that profile IDs, predicates, required criteria, and stable reasons are contracts; it also defines opt-in selection precedence and startup validation for an invalid explicit profile. Those are product and upgrade commitments requiring maintainer approval. (rfcs/0023/hosting-profile-v1-spec.md:1, e931e8d95e15)
• Dependency is unresolved: The PR body and RFC identify RFC 0018 as the owner of the readiness evaluator and condition model, while the supplied related-item context shows RFC 0018 is still open at RFC 0018: Readiness Conditions and Providers #33. This RFC therefore cannot be treated as documentation for an already-settled core contract. (rfcs/0023-standard-hosting-profiles.md:1, e931e8d95e15)
• Implementation remains an open upstream path: The PR body identifies feat(hosting): add profile inspection and conformance tooling openclaw#114636 as the upstream implementation for inspection, live validation, and conformance tooling; the supplied timeline records that pull request as open, not merged provenance. (rfcs/0023-standard-hosting-profiles.md:1, e931e8d95e15)
• Prior review continuity: The previous completed ClawSweeper cycle found no line-level defects and correctly classified the changed surface as RFC Markdown only. The current head remains a two-file documentation proposal, so runtime proof is not a merge gate for this PR itself. (rfcs/0023-standard-hosting-profiles.md:1, e931e8d95e15)

Likely related people:

• giodl73-repo: Authored the current RFC branch and the related open readiness RFC, and also appears in the supplied repository history as author of the previously merged hosted-feeds RFC. (role: proposal and related-RFC author; confidence: medium; commits: e931e8d95e15, db5d2afb9e13; files: rfcs/0023-standard-hosting-profiles.md, rfcs/0023/hosting-profile-v1-spec.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Obtain explicit maintainer sponsorship or a decision on the four-profile v1 catalog and its compatibility boundary.
• Keep RFC 0018 and the linked implementation work independently reviewable rather than treating external implementation assertions as acceptance of this RFC.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (31 earlier review cycles; latest 8 shown)

• reviewed 2026-07-27T16:09:14.273Z sha ea2c578 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T16:13:58.463Z sha ea2c578 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T16:36:22.039Z sha cfa0531 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T17:09:43.402Z sha cfa0531 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T17:29:14.048Z sha cfa0531 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T17:44:51.081Z sha 41b3857 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T22:07:59.688Z sha 41b3857 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-27T22:14:19.056Z sha 41b3857 :: needs real behavior proof before merge. :: none

[giodl73-repo]

RFC 0023 now makes standard hosting profiles explicitly opt-in. An upgrade with no profile selected preserves RFC 0018's existing readiness baseline; selecting local, container, reverse-proxy, or node-mode adds the named support posture and its required conditions.

The implementation stack is rebased onto readiness head 17b34f792d8 and the exact package-installed proof is recorded on openclaw/openclaw#107765. It begins with an unprofiled 200 compatibility case, then exercises all four explicit profiles and their failure/recovery transitions.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The durable review comment was published and its verdict was queued for target-serialized routing.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29481347753
• Updated: 2026-07-16T07:54:35.104Z