Notes from the AI cloud
Engineering deep-dives, product stories, and field notes from the team building DODIL — DataK3, Ignite, Models, and Scriptum.
Latest
Build a module on DODIL: from 'I want a CRM' to a running system, in seven steps
The DODIL enterprise packages are reference implementations, not product. An agent reads one, interviews the customer, and GENERATES their system — their objects, their stages, their approvals, their org chart — copying the platform layer verbatim. This is the canonical flow: discover, fetch, derive, generate, provision, deploy, verify; the per-customer topology (one pool, one bucket, one app per module by default); what adding a module actually means (same pool, same bucket, one more router); and the invariants you copy rather than regenerate — each one a scar from a live failure.
Ship a DODIL app the supported way: git push → CI → registry → CD → a gated URL
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.
Auth Is Config, Not Code: End-User and Platform Sign-In for DODIL Apps
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.
Who-Can-Do-What Without a Policy Server: App Authorization on DODIL with dodil-appid
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.
Watch the Floor: Visual Retail Analytics on DODIL — Footfall, Dwell, Segmentation, Journeys, and Loss Prevention from Your Camera Feeds
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.
Financial-Services GL on DODIL
The General Ledger suite, reshaped for a regulated SOX-style close — journals that carry a preparer, an approver and an approval state, an immutable approval trail, and a segregation-of-duties hard gate that blocks a self-approved journal from posting even when it balances. A period can't close while any journal in it is unapproved. It's the GL suite plus one additive overlay, on the same bucket.
Tutorials
View all →Ship a DODIL app the supported way: git push → CI → registry → CD → a gated URL
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.
Auth Is Config, Not Code: End-User and Platform Sign-In for DODIL Apps
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.
Who-Can-Do-What Without a Policy Server: App Authorization on DODIL with dodil-appid
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.
Engineering
View all →Build a module on DODIL: from 'I want a CRM' to a running system, in seven steps
The DODIL enterprise packages are reference implementations, not product. An agent reads one, interviews the customer, and GENERATES their system — their objects, their stages, their approvals, their org chart — copying the platform layer verbatim. This is the canonical flow: discover, fetch, derive, generate, provision, deploy, verify; the per-customer topology (one pool, one bucket, one app per module by default); what adding a module actually means (same pool, same bucket, one more router); and the invariants you copy rather than regenerate — each one a scar from a live failure.
Our Thesis, and Why Now
Why we're building one agent-native AI-data platform on sovereign EMEA hardware — the three curves that made now the moment, what we collapse, and what actually ships today.
From Zero to Building in Two Minutes: CLI, Login, and Your Agent
Register, install the dodil CLI, log in, and connect your agent (Claude Code, Cursor, VS Code, Codex) over MCP — the whole DODIL setup, once.