Inkloom: logo construction models shipped without the generation feature

A repo published for audit, not for use

The README explains why the source is public in its own section: it is published so the engineering can be read and audited, in particular the security and data-handling claims. The next sentence removes any ambiguity about what you can do with it. It is not a distribution, and readers are pointed at the LICENCE file rather than offered a grant. The footer reinforces this with an all rights reserved notice.

That framing is unusual and worth taking seriously rather than skimming past. Most public repositories are implicitly licensed; this one has to be checked deliberately, and the absence of releases makes that clearer. There are zero tags and zero published releases, so there is no version to install and nothing to pin. GitHub reports the license as NOASSERTION, which is consistent with a proprietary licence that the detection heuristics cannot classify.

The repository has 1418 stars and 1452 forks. More forks than stars is an unusual ratio and it is the most telling number here. Forking is what people do when they want to read and adapt rather than use, which is exactly the behaviour an audit-focused publication invites.

The operational documentation is deliberately absent. Deployment, incident response, environment and runbooks are kept internal, and the README preempts the complaint by explaining why: it describes how the service is operated, which is of no use to a reader and of some use to an attacker. Source comments sometimes point at those internal files by name. That is a considered trade rather than an oversight.

The four stage pipeline that does not exist yet

The README's central claim is a staged model of logo construction, presented as a table. Brand analysis turns a description of a business into concrete constraints: sector, audience, tone and competitors in, stroke weight, width, geometry and counter shape out, plus a judgement on which symbol families fit. Typography selects and fits letterforms against those constraints and does the work that makes a wordmark, meaning optical spacing, kerning at display size, and a custom ligature where the name needs one. Symbol construction composes geometric primitives under rules about shared radii, tangent junctions and consistent terminals. Composition handles optical alignment rather than mathematical centring, derives clear-space ratios from the mark's own geometry, and produces lockup variants.

The argument the README makes against general image models is the interesting part, and it is a real one. A logo is described as a constructed object with rules rather than a picture: a mark that has to hold at sixteen pixels and on the side of a building, letterforms spaced by eye, clear space derived from the mark itself. General image models produce something logo-shaped, in the README's phrasing, with no construction behind it and nothing you can hand to a printer.

Then comes the sentence that decides how to read everything above it. Generation is not live yet. The README says it would rather say that plainly than imply otherwise, notes that every page in the product says so, that credits are reserved rather than spendable, and that the feature flags which would switch generation on default to off and cannot be toggled from the console. The reasoning is stated too: enabling a flag whose feature does not exist exposes a broken surface rather than a feature.

So the four stage table describes a design. Nothing in the repository implements it. Read it as a specification to evaluate later, not as documentation of current behaviour.

What actually runs today

The README is specific about the present state, and it is a list of platform features: accounts and authentication, the credit ledger, the access-code system, the operations console, and the machinery around them. Three items in that list are described with a precision that tells you the team has been burned by the usual failures.

Backups are said to be restore-tested rather than merely taken. An alerting pair is described where each half watches what the other cannot see, which is a standard answer to the correlated-failure blind spot. And the deployment path refuses to migrate a database whose identity has not been confirmed.

The monorepo supports those claims structurally. It is a pnpm workspace on Node 22 or newer, with scripts covering database generation, migration, status, a verify-target step, seeding and reset, account erasure, credit reconciliation, campaign code creation, secrets checking, production acceptance, health checking and a retention sweep. Several of those scripts exist to protect properties rather than to add features, and `db:verify-target` and `credits:reconcile` are the two that most directly encode the README's claims about migration safety and ledger integrity.

Early access is open at inkloom.art. The README describes the flow as creating an account, redeeming a code, and having credits reserved against the account. The distinction between reserved and spendable is the same distinction as not live and live, applied to money instead of images.

Tests against real infrastructure, and the one that matters

The test strategy is stated as a position rather than a feature list. The suite runs against a real database, a real browser and a real mail server rather than mocks, and the stated reason is that the guarantees that matter are transaction guarantees and a mock cannot have one.

That reasoning is correct, and it is rare to see written down. Most projects mock the database for unit tests because it is faster, then discover that concurrency behaviour cannot be tested at all. This one commits to the slow path and names the specific test that justifies it: twenty-five simultaneous redemptions of a single code fired at a real database, asserting that exactly one redemption, one ledger entry and one balance exist afterwards.

That is the test to read first if you are evaluating the redemption design, because it is the only assertion in the repository that distinguishes a correct implementation from an almost correct one. Twenty-five concurrent claims on one access code is the classic oversell bug, and the assertion is stated in terms of all three affected tables rather than just the code row.

The tooling supports both halves of the approach. Vitest runs unit, integration and security projects, with `test:security` as its own target and integration split out separately. Playwright has two configurations, a default one and a live one, and a dedicated end-to-end script. Locally, Docker Compose brings up Postgres 17 on port 5433 bound to loopback and Mailpit on 1025 and 8025, with deliberately weak local-only credentials and a healthcheck on each. The Postgres service is initialised with a deterministic ICU collation so that ordering matches Neon, which is a small detail that prevents a class of test failures that would otherwise be baffling.

Cloudflare Workers, one origin, and secrets that never touch a file

The stack is Cloudflare Workers, Postgres and React Router, with the application and its API served from one origin. The README names that single-origin choice as the reason the session cookie is first-party and cross-origin handling disappears entirely, which is the correct way to build this and a good sign about the rest.

The secrets story is the most transferable part of the whole repository. The `.env.example` file opens by describing itself as an environment contract and states that in staging and production these values are not read from a file at all. Non-secret values live in `wrangler.jsonc` under `vars`, and every secret is set with `wrangler secret put NAME` and stored in Cloudflare Secrets. The `.env` file is gitignored, and the example file says so. The compose file repeats the point with a comment block explaining that production uses Neon PostgreSQL and Resend, that nothing in the compose file is deployed, and that the credentials there are intentionally weak and bound to 127.0.0.1.

Two details are worth calling out. First, `INKLOOM_ENV` is documented as one of development, staging or production, controlling cookie security, error verbosity and which safety rails are armed, which is the kind of single switch that keeps behaviour from drifting across environments. Second, the compose file sets `MP_SMTP_AUTH_ACCEPT_ANY: 1` and `MP_SMTP_AUTH_ALLOW_INSECURE: 1` on Mailpit, which is correct for a local mail sink and would be alarming in any other context. Reading these two files together tells you more about how this team works than any amount of prose in the README.

Editorial conclusion

What is worth reading here is the operational engineering, not the models. There is no code in this repository that constructs a logo, and the README says so in plain words, so anyone evaluating Inkloom for its AI capability is looking at the wrong repository. What the tree does contain is a disciplined account platform: a credit ledger with a reconciliation script, an access code system whose concurrency guarantee is asserted by a test that fires twenty-five simultaneous redemptions at a real database, a migration path that refuses to run against an unverified database identity, and secrets handled entirely through Cloudflare rather than files. The README also states plainly that this is not a distribution and points at a LICENCE file rather than granting one. If you want to study how a small team ships an audited billing and redemption system on Cloudflare Workers, the code is genuinely instructive. If you want a logo, the product page says generation is not live yet.

Frequently asked questions

Official sources

1. Inkloom-art/inkloom on GitHub
2. Issues
3. Project website
4. README