Today we are launching the alpha of Naftiko Framework and Naftiko Fleet. This is one of four posts going up to set the table for what that actually means and how to put Naftiko to work. This one is the fastest way in — a Hello World capability you can run in under a minute. The other three cover the underlying capability specification, the framework engine and CLI that runs it, and the Fleet tooling that turns one capability into a governed inventory.
The fastest way to understand any framework is to run it. Not read about it. Not browse the specification. Not watch a demo. Run it yourself and see what happens. The Naftiko Framework Hello World capability is the smallest possible proof that Spec-Driven Integration works — and it takes under a minute from a cold start.
One YAML file. One Docker command. A running API endpoint.
What You Need
Docker. That’s it. If you have Docker Desktop running on your machine, you have everything you need. No Java installation. No build tools. No package managers. No language runtimes to configure. The Naftiko engine ships as a container image on Docker Hub, and it’s public — no authentication required to pull it.
docker pull naftiko/framework:1.0.0-alpha1
That gives you the v1.0 Alpha 1 engine. It’s a JVM-based runtime that reads a capability YAML file and starts serving immediately. The image is small, the startup time is measured in milliseconds, and the resource footprint is minimal.
The Capability File
Here’s the entire Hello World capability:
naftiko: "1.0.0-alpha1"
capability:
exposes:
- type: "rest"
port: 8081
namespace: "tutorial"
resources:
- path: "/hello"
name: "hello"
label: "My first resource"
description: "A simple Hello, World! API endpoint"
operations:
- method: "GET"
outputParameters:
- type: "string"
const: "Hello, World!"
Fifteen lines. No imports, no dependencies, no boilerplate. The file declares exactly one thing: expose a REST endpoint at /hello that responds to GET requests with a constant string. The naftiko: "1.0.0-alpha1" header tells the engine which schema version to use. The exposes block defines what the capability makes available to the outside world. The resources block defines the endpoint. The operations block defines the HTTP method and what it returns.
That’s the entire integration. The specification is the implementation.
Running It
Save that YAML file and mount it into the Docker container:
docker run -p 8081:8081 \
-v /path/to/hello-world.capability.yaml:/app/hello-world.capability.yaml \
naftiko/framework:1.0.0-alpha1 /app/hello-world.capability.yaml
The engine reads the file, spins up a Jetty HTTP server on port 8081, and starts serving. You’ll see the startup log confirm it:
Reading configuration from: /app/hello-world.capability.yaml
Starting the Jetty [HTTP/1.1] server on port 8081
Capability started successfully.
Now hit the endpoint:
curl http://localhost:8081/hello
{
"value": "Hello, World!"
}
That’s it. You have a running capability.
What Just Happened
Something important happened in those fifteen lines and one Docker command, and it’s easy to miss because it looks simple.
You didn’t write any application code. You didn’t configure a web server. You didn’t set up routing, request handling, response serialization, or any of the infrastructure that normally sits between your intent and a working endpoint. You declared what you wanted — a REST endpoint that returns a string — and the engine handled everything else.
This is what Spec-Driven Integration means in practice. The specification isn’t documentation that describes code you still need to write. The specification is the executable artifact. The Naftiko engine interprets it directly at runtime. There’s no code generation step, no compilation, no build pipeline. What you declare is what you get.
The Hello World capability only uses the exposes side of the framework. It’s a capability that produces but doesn’t consume. In a real integration, you’d also have a consumes block that declares the external APIs you’re calling — think of it as the difference between a ship loading containers at dock versus one that’s also receiving cargo from incoming vessels. The consume side brings data in from external APIs; the expose side serves it out through your capability’s interface. The engine sits in the middle, handling the orchestration.
Where to Go From Here
The Hello World is Step 1 in the Naftiko tutorial. Each subsequent step adds a layer of capability:
Step 2 — Forwarding. Add a consumes block that points to an external API like Notion, and forward requests through your capability. Your capability becomes a proxy with a clean namespace.
Step 3 — Encapsulating Headers. Move authentication tokens and version headers into the consumes configuration so consumers of your capability don’t need to manage them. Pass secrets as environment variables to the Docker container.
Step 4 — Filtering Responses. Use outputParameters with JSONPath mappings to return only the fields you need. Shape the response for your specific use case instead of passing through everything the upstream API returns.
Step 5 — Multi-Step Orchestration. Chain API calls using steps, where the output of one call feeds the input of the next. A single capability endpoint can orchestrate multiple upstream operations and return a composed result.
Step 6 — MCP Exposure. Switch the expose type from rest to mcp and your capability becomes an MCP tool that AI agents can discover and invoke. Same consume logic, different exposure protocol.
Each step builds on the same foundation: a YAML file interpreted by the engine. No new languages to learn. No framework APIs to memorize. Just more fields in the specification.
Why Hello World Matters
Every framework has a Hello World. Most of them are trivial by design — they exist to verify your toolchain works. The Naftiko Hello World is different because the gap between it and a production capability is not a gap in language or architecture. It’s a gap in YAML fields.
Going from Hello World to a real integration that consumes the GitHub API, filters the response, and exposes it as an MCP tool doesn’t require learning a programming language, adopting a framework’s opinion about project structure, or setting up a build system. It requires adding a consumes block and some outputParameters. The same engine. The same Docker command. The same deployment model.
That’s the point of running Hello World first. Not to prove that the framework can return a string. But to prove that the distance between a toy example and a real integration is measured in specification lines, not in architectural complexity.
Pull the image. Write the YAML. Run the container. Your first capability is live.
