// the take
deco is the open-source engine behind deco.cx's visual CMS: a Deno/Fresh/Preact stack where TypeScript interfaces on your components get turned into a content-editor UI automatically, with changes committed to git. It's aimed at teams building ecommerce storefronts or marketing sites who want non-engineers editing content without touching code, while engineers keep working in TypeScript.
The Props-to-UI generation is a genuinely good idea — you write a normal TypeScript interface and get a form UI for free, with type-matching used to suggest compatible data sources (loaders) for a given component. The caching layer is properly built for production: file system, Redis, LRU and a tiered composition of them, not just an afterthought. OpenTelemetry instrumentation and probes (latency, uptime, memory) are wired in rather than bolted on later. The schema/manifest generation that walks your TypeScript AST to build the block system is non-trivial tooling that clearly took real engineering effort.
This is the engine for a commercial SaaS, not a standalone framework — the README's own warning says self-hosting the editor is 'coming in early 2025,' and it's now late 2026 with no sign that shipped, which tells you where the maintainers' priorities actually are. The ecosystem (apps marketplace, hosting tiers, a $99/mo PRO plan) is central to how this is meant to be used, so adopting it as pure open infrastructure fights the grain of the project. You're locked into Deno + Fresh + Preact + HTMX specifically; this isn't a CMS you bring to an existing React/Next or Vue stack. The realtime sync layer (CRDT text/bit types, decofile providers, a daemon with PTY sessions and sandboxed worker isolates) is a lot of distributed-systems surface area for what's billed as a CMS, and debugging it yourself without the deco.cx dashboard looks like a rough experience.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →