Guides and CI-tested working examples for building unikernel images

[scotwells]

Goal

Give users trustworthy, worked starting points for running their applications on Datum compute: a catalog of working example apps that build into unikernel images and boot on the platform, and per-language guides that walk from an empty directory to a deployed app serving traffic.

Why

A familiar build command (#174) is necessary but not sufficient. Users evaluate a platform by finding their language, copying a known-good starting point, and adapting it — that's the experience other popular providers offer through per-framework guides and example repos. Without equivalents, every user rediscovers unikernel packaging constraints by trial and error, and the first impression of the platform is a boot failure instead of a running app.

Scope

• Working examples — small, realistic apps for common languages (Node, Go, Python at minimum; framework variants over time), each with a Dockerfile, that build with the build plugin and boot and serve traffic on Datum compute.
• CI-tested — every example builds and deploys green in CI so examples can't rot; a broken example fails the build. (Model: Unikraft's application catalog.)
• Per-language guides — walkthroughs from empty directory to a built image in the user's own registry to a deployed workload, modeled on the per-language guides Unikraft and other providers publish.
• The build plugin's one-page quickstart remains part of datumctl build plugin: build unikernel OCI images and push to any registry #174; these guides build on it rather than replacing it.

Language support

Deploy guides with runnable examples are already open for six languages — Go (#130), Rust (#131), Node.js (#132), Python (#133), PHP (#134), Ruby (#135) — with the examples under examples/hello-*. This issue turns that set into a supported matrix rather than starting from scratch:

• Launch (supported at 1.0): Node.js, Go, Python — the highest-demand deploy languages. Land their guide PRs first, wired to CI and routed through the build plugin.
• Fast follow: Rust, PHP, Ruby — guide PRs exist; promote each to supported once the launch set ships.
• On demand: Java (Spring Boot) and framework variants of the launch languages (Express, FastAPI, Flask, …) — Unikraft publishes upstream guides for these; add based on user demand rather than up front.

"Supported" means all three hold: the language works through the build plugin's Dockerfile flow, its example is CI-tested, and its guide is published. Anything missing one of the three is a work in progress, not supported. The open guide PRs predate the build plugin, so part of this work is updating their build steps to go through #174 once it lands.

Acceptance criteria

From the consumer's point of view:

• I can find an example for my language (Node, Go, Python at minimum), copy it, and have it running on Datum compute by following its guide — no unikernel knowledge required.
• Each guide takes me from an empty directory to a deployed app serving traffic, pushing through my own registry along the way.
• Each example is a realistic minimal app I can adapt — it doesn't hide the parts I'll need to change for my own application.
• What I copy is known-good: examples are exercised in CI, and a broken example fails the build.
• Commands shown in guides are copy-pasteable against the current build plugin — guides are updated when the plugin UX changes.

References

• datumctl build plugin: build unikernel OCI images and push to any registry #174 — the datumctl build plugin these guides and examples are built around
• Unikraft guides index, e.g. Node, Go, Python — the per-language walkthrough shape to model
• Unikraft application catalog — the CI-tested example-repo model