Hands-on guides.

Step-by-step tutorials for shipping real things on Gonkablocks. Every guide ends with something you've actually deployed — not a quote-along reference. Pair with the full reference docs when you need a specific field or flag.

Foundations

1. 01 · Build

   Create your first block

   Package a Python script as a real, deployable block. Walks through the manifest, Dockerfile, inference SDK, inputs/outputs, building, testing, and publishing — with full code at every step.

   01Choose a block type02Write manifest.yaml + Dockerfile03Read inputs, call inference, write outputs04Deploy with the CLI05Test, iterate, publish
2. 02 · Ship

   Make a block externally accessible

   Five patterns to expose a block to the outside world: the public block page, the embeddable widget, services as live HTTP endpoints, the CLI, and the REST API. Including auth, secrets, and shareable runs.

   01Make it public02Embed as an iframe03Run from the CLI04Deploy as a Service (HTTP endpoint)05Trigger via REST API + scoped keys06Share single runs by link

Integrate

Hook other tools and agents into the platform. Same account, same credit, same blocks — surfaced wherever you already work.

1. 03 · Integrate

   Connect AI agents via MCP

   Plug Cursor, Claude Desktop, Continue, Cline, or Zed into Gonkablocks. The agent gets 38 tools — search, run, build, deploy — backed by your account credit. Includes the install snippets for each client and the safety model.

   01Install the MCP server02Connect to your account03Wire it into Cursor / Claude / Continue04Tools, prompts, resources05Permissions & safety

Master each block type

One in-depth page per block type, with full working code. Pick the type that matches your goal, follow the page end-to-end, and you'll have something deployed and callable on prod by the time you're done.

1. Block type · job

   Build a job block

   One-shot, exits-when-done. The bread-and-butter type — most blocks on the platform are jobs. Walks all the way from `mkdir` to a verified successful run, with the same code I used to test the platform end-to-end.

   01When to pick job02manifest + Dockerfile + main.py03Deploy & run04Iterate (versions)05Pitfalls I actually hit
2. Block type · worker

   Build a worker block

   A job that the platform fires on a schedule. Same source code as a job — the only thing that changes is the type in the manifest, plus a cron expression you register once. Includes cron syntax cheatsheet and spend-cap math.

   01When to pick worker02Schedule via API or UI03Cron syntax cheatsheet04Watch the scheduler fire it05Spend caps & pitfalls
3. Block type · session

   Build a session block

   Long-running, per-user container — the platform spins it up on demand, proxies HTTP through to it, and reaps it when the user goes idle. Pick this when you'd write 'an app' rather than 'a script'.

   01When to pick session02FastAPI HTML chat03Proxy paths & user headers04Idle reaping & graceful stop05Pitfalls I actually hit
4. Block type · service

   Build a service block

   Long-running HTTP server — one container, shared by everyone, reachable at a stable public URL. Pick this when you want a REST endpoint that other systems can call: webhooks, MCP servers, integrations.

   01Service vs. session02Deploy & redeploy atomically03Public vs. private04Stop & spend caps05Chunked-body proxy gotcha
5. Block type · workflow

   Build a workflow block

   A directed graph of other blocks. No Dockerfile, no Python — wire existing blocks together visually (or via REST), publish the workflow as its own block, and run the whole DAG with one call.

   01When to pick workflow02Graph shape (input/block/output)03Save graph + publish04Data flow & types05Spend caps & failure modes