Tutorials

Every DODIL tutorial builds an engine and stops at shown-as-code. This is the supported last mile, and it is git-driven: push to a DODIL repo, the forge runs your .github/workflows/ci.yml with the registry credentials already injected, the image lands in registry.dodil.io, and an in-repo .dodil/deploy.yaml applies it to an Ignite app — runtime credentials resolved from the repo's secret store at deploy time, end-user login done by the gateway, neither one written by you. One org, one bill, one auth context, no GitHub, no Docker Hub, no external CI.

Every app you build on DODIL serves two kinds of caller: business users who log in (sales reps, customers, guests) and platform principals (service accounts, CI, other services) that call it machine-to-machine. On DODIL that is a config decision, not an auth library. Attach a dodil-appid pool to an Ignite app and the per-cluster gateway runs the whole browser login — PKCE S256, an AEAD-sealed host-only session cookie, single-flight refresh — then injects X-Dodil-User, X-Dodil-User-Jwt and X-Dodil-Auth-Source into your request. The app ships no auth code. Platform callers keep working alongside, because the model is additive. And when you are NOT behind that gateway, you verify the pool's EdDSA JWT yourself against its JWKS with iss AND aud mandatory.

Your app on DODIL knows who the user is — now it needs to know what they can do. A rep sees only their deals; an approver can approve invoices. The usual answers are a policy server (OPA, a permissions microservice) you call on every request, or authz logic smeared through the app. dodil-appid does RBAC in the token: a per-pool role catalog maps roles to resource:action permissions, a user's roles expand into a permissions claim on their JWT, and the app checks permissions locally with zero round-trips. Behind the Ignite gateway that token arrives already verified in X-Dodil-User-Jwt, so the app reads permissions off an injected header and verifies nothing. Tenants add per-subsidiary roles and tenant-pinned tokens — the ERP layer. And the two-plane rule holds: appid says who and what-role; the app filters rows by sub via its own service account, because bucket RBAC can't do per-row authz.

Turn the IP cameras a retail chain already has into one analytics system on a single DODIL bucket: anonymous footfall/dwell/queue metrics (SQL), shopper segmentation and appearance re-ID (a VECTOR(2048) table + jina-embeddings-v4), in-store journeys (a zone graph), loss-prevention and safety alerts, and a consolidated HQ layer over 15 branches in 7 countries — 494,868 entries and £5,505,309.98 of FX-consolidated revenue, a branch league table and an outlier band. Four live perception models (mm-gdino-large, scrfd-34g, arcface-r100, jina image), a per-camera sampling dial that keeps inference cheap, an app-configurable consent-first identity model that is off by default, and a FastAPI + React app that ships on a git push.

An object store for files, Postgres for rows, Pinecone for vectors, Neo4j for the graph — four vendors, four bills, and sync jobs whose only purpose is to keep the copies from drifting. DataK3 is one bucket that is all four at once over a single copy: raw files as objects, and the same rows queried by SQL (Postgres wire), vector KNN (pgvector), and graph (Bolt). Point psql, sqlx/diesel, psycopg/asyncpg, node-postgres, and a Neo4j driver straight at fixed endpoints, keep raw files in the same bucket via the object API, and retire the other three stores. No export, no proprietary SDK, no driver rewrite.

A semantic cache in front of your agent — exact-hash fast path, document-rag near-duplicate match, answers in S3 — wrapped in an Ignite function, with an event-sourced warehouse that tracks hit-rate, dollars saved, and embedding drift.

Auto-sync every repo and branch from GitHub into one DataK3 bucket, so every developer's agent searches code by intent across all branches — with the 'why' embedded next to the code.

Stand up a DataK3 warehouse, source a multi-year filings backfill plus a daily news firehose into it, batch-analyze hundreds of thousands of documents on a low-cost model in parallel, then query structured signals with SQL, walk an issuer/sector/supply-chain graph to size blast radius, and search filings by meaning — all over one bucket.

Stand up a DataK3 warehouse, discover orgs into it, classify 200,000 companies on a low-cost model into a queryable organizations table, propagate ICP-fit across corporate families with a graph, dedup lookalikes with vectors, then open only the qualified into people — one bucket, three pillars.

Capture immense raw telemetry, track exact calibration metadata, and semantically search signal anomalies — with the CLI or by prompting an agent.

Dump raw PCAPs and logs into cold storage while running semantic anomaly detection and incident tracking on one DataK3 bucket — with the CLI or by prompting an agent.

Store product media and catalog assets while tracking live sales and enabling semantic and visual product discovery — with the CLI or by prompting an agent.