marketing: reflect workload-spec + metrics + signed-release model#129
Merged
Conversation
The hero and architecture sections still described the pre-rewrite
workspace layout (dd-client / dd-register / dd-web as separate
binaries alongside easyenclave). The workspace was collapsed back
into a single devopsdefender binary with cp + agent modes in the
April rewrite — and easyenclave is a separate upstream project, not
a DD-shipped binary.
- "4 Binaries: dd-client, dd-register, dd-web, easyenclave"
→ "1 Binary: devopsdefender (cp + agent modes)"
- architecture subtitle: "4 binaries, 2 repos" → "1 binary, 2 modes"
- architecture diagram: unified devopsdefender agent / cp workloads
instead of dd-client + dd-register + dd-web.
- model: gemma4:e2b → llama3.1:8b (prod GPU) / qwen2.5:0.5b
(preview CPU), matching scripts/ollama-deploy.sh.
- mention podman — the containerized ollama+OpenClaw stack is how
we actually run it.
"Powered by easyenclave" callout + footer link unchanged (those
were already correct — it IS the PID 1 runtime).
Still misleading: the deploy-workload / verify-deployment composite
action snippet (those actions were removed in the workspace
rewrite, PR #71). Separate decision.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three months of iteration have solidified how DD actually deploys
and measures things. Update the landing page so it matches:
* **How It Works** steps now cover: Declare a workload JSON spec,
Deploy via the composite action or bake as a boot workload,
Attest & run (TDX + Intel ITA verify at /register; live fleet
metrics). Less "push a container image"; more "drop a JSON".
* **Deploy example** switches to inline `deploy-spec-inline` YAML
heredoc (file form stays commented out above). Follows the
ergonomic default we land in the composite action. Adds a line
naming the on-disk convention (`apps/<name>/workload.json`) so
users know where to put long specs.
* **Features** cards:
- Fleet Management → Fleet Metrics — mention per-disk capacity
and per-NIC rx/tx (PR #126) plus in-browser terminal.
- API-Driven Deploys → Workloads as JSON — leads with the apps/
tree as the single source of truth.
- New: Signed Releases — Sigstore-backed GitHub attestations on
every published binary (PR #125); `gh attestation verify`
proves provenance.
- Cloudflare Tunnels — drop "dd-register" in favour of "the CP".
* **Architecture diagram** re-organised:
- easyenclave spawns workloads from apps/*/workload.json.
- Podman shows up as its own workload step, with ollama + openclaw
running as a container on top — matches the current reality
(PR #127's boot-workload chain).
- Subtitle becomes "1 binary, 2 modes, workloads as code".
* **Code-block `.c` class** added to style.css — renders commented
lines dim/italic so the file-vs-inline split in the example reads
cleanly.
* Powered-by EasyEnclave callout + footer links unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
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.
Summary
Three months of iteration have solidified how DD actually deploys + measures things. Update the landing page to match.
How It Works — three steps, updated
apps/<name>/workload.json(or inline in the workflow).deploy-workloadaction POSTs the spec to/deploy. Or bake it as a boot workload./register; fleet streams live CPU + disk + NIC metrics.Deploy example — inline + on-disk convention
deploy-spec-inline:heredoc is the active form;deploy-spec:file path stays commented out above for copy-paste convenience. Adds a note that on-disk specs live atapps/<name>/workload.json.Feature cards
apps/tree.Architecture diagram
apps/*/workload.json.Plumbing
Adds
.cclass to style.css (dim/italic) for commented lines in code blocks. Thedeploy-specfile-path line in the inline-spec example uses it.Test plan
pr-preview/pr-N/— eyeball the hero, steps, features, architecture diagram, and deploy example. Commented line should render dim/italic.🤖 Generated with Claude Code