Part of the honest comparison series — see also Magic vs Directus, Magic vs PocketBase, Magic vs n8n and Magic vs DreamFactory.
Unqork was founded in 2017. It has raised roughly $365 million — $131 million in a Series B in February 2020, $207 million in a Series C that October, led by funds managed by BlackRock, with CapitalG, Goldman Sachs, Hewlett Packard Enterprise and Eldridge along for the ride — at a valuation north of $2 billion.
Hyperlambda is from 2013. The current Magic codebase is from 2019, ported from Phosphorus Five, which is older still.
I mention the dates first because every article written about Unqork frames them as the pioneers of codeless enterprise development and everyone else as a follower. The chronology does not support that. They arrived four years late, spent a third of a billion dollars, and landed on an architecture that is worse in ways I can demonstrate from their own published material rather than from opinion.
That is the whole article. Everything below is evidence.
What an Unqork application actually is
In February 2024 Unqork published what they called the first open-source specification for codeless applications. It is a genuinely useful thing to have published, because it means nobody has to take my word for any of this. Here is the canonical component example, copied from their own repository's README:
{
"key": "exampleComponent99",
"type": "example",
"eventHandlers": {
"ON_CLICK": {
"operations": [
{
"type": "SET_PROPERTY",
"options": {
"target": "myConfettiComponent",
"property": "hideConfetti",
"value": false
}
}
]
}
},
"exampleSpecificProperties": {
"superSpecificToExample": true
}
}
That is fifteen lines to set one boolean on one component when somebody clicks something. Here are five lines of Hyperlambda:
data.read
table:customers
where
and
id.eq:x:@.arguments/id
That queries a database.
I am not making a like-for-like feature comparison, and I want to be explicit about that because it would be dishonest to pretend a UI component and a database read are the same job. The comparison is of formats, and the format comparison is not close. One of these is written for a person. The other is an abstract syntax tree that has been serialised to JSON and then published as though it were a source language.
That is the thesis of this entire article: Unqork kept the tree and threw away the syntax.
Lisp settled this question in 1958. You can have a data structure that is also a program, and the win is enormous — but only if a human can read it. Unqork built the data structure and skipped the reading part. Hyperlambda is the same idea done the other way round: an indentation-based tree where the text is the node graph and the node graph is the text, so the same artefact serves the parser and the person. The full explanation is here.
Four consequences, none of which are opinions
1. An Unqork application cannot document itself. JSON has no comment syntax. There is nowhere for the "why" to live next to the "what". Every non-trivial system accumulates decisions that are invisible from the code and catastrophic to forget, and Unqork's artefact format has no place to put a single one of them.
2. It does not diff. Auto-generated keys like exampleComponent99, deep nesting, no stable ordering. Ask any of their customers what a merge conflict looks like. Actually, don't — their own user reviews say it for me: version control was "a missing basic functionality that was only introduced recently", and that visual version control "needs advancement for better design history, branching, merging, and reverting changes." That is not a roadmap gap. That is the JSON-blob-in-a-document-store choice arriving as a product complaint, eight years in.
3. The IDE is not a convenience, it is a hard dependency. Nobody reads or writes that JSON by hand. Which means the artefact is inert without UDesigner, which means the vendor is not a hosting provider, the vendor is a precondition for your application existing. Hold that thought for the lock-in section.
4. Execution order is emergent rather than written. Behaviour falls out of eventHandlers, watchers and signals chaining across components. You cannot read the order of operations off the page, because the order of operations is not on the page. It is a property of the graph at runtime. This is why the debugging complaints in their reviews exist, and it is not fixable without changing the format.
Where the logic runs, which is the part that should worry a bank
This is the finding I did not expect, and it is the most serious thing in this article.
By default, Unqork executes your module logic in the end user's browser. They call it Express View. Server-side execution is an opt-in module type that you have to know about and choose.
It gets better. Their documentation also describes a construct called a proxy module, whose stated purpose is to sit between a front-end module and a remote execute and "force-validate the Front-End module's data after submission" to ensure "the data maintains its original form without manipulation." Why is that needed? Their docs answer that too: because if an API call runs in the browser, "any end-user can open the DevTools Console and inject malware or access private information."
Read that again with the marketing in your other hand. This is the platform sold to the world's largest regulated businesses on the strength of governance and security being built in from day one. The secure path is opt-in. It requires correctly configuring two additional module types. Every time. By a builder the platform explicitly markets as not needing to be a software engineer.
Security that depends on developer discipline is not built in. It is a checklist, and checklists fail at scale. Magic endpoints execute server-side. There is no browser option, so there is no way to get it wrong — and authorisation is enforced at the runtime on every invocation, not in a component you might forget to add.
Five languages, none of which compose
Unqork expresses business logic through Calculator, Decisions, Initializer, Plug-In and Data Workflow components. That is five separate paradigms: formula strings with aliases, input-output decision tables, initialisation blocks, integration plug-ins, and a visual dataflow graph with its own operator vocabulary.
They do not compose with each other. A formula cannot call a dataflow. A decision table cannot be a subexpression. Each one is a little walled garden with its own mental model, its own failure modes and its own debugging story, and the moment a requirement spans two of them you are gluing paradigms together by passing values through component keys.
Hyperlambda has one construct: a tree of slot invocations. Around 420 slots across 40 plugins in the current codebase, all uniformly composable, all the same shape. You learn the shape once.
This is why Unqork's own reviewers report frustration when their needs "deviate from Unqork's pre-defined paths", and why one suggests the platform "could benefit from allowing more flexibility in creating projects and extending them to other languages like JavaScript, Angular, or React." That is a user asking for an escape hatch. There isn't one.
The open-source claim, examined
Unqork's Winter 2024 press release announced "the First Open Source Specifications for Codeless Applications", framed as giving customers "total access to their Unqork specification ecosystem" and reducing lock-in.
Here is that repository as it stands:
| Stars | 3 |
| Forks | 1 |
| Contributors | 2, both Unqork service accounts |
| Contributions | "Contributions to this repository are currently not accepted." |
| Licence | AGPLv3, with "contact us at runtime@unqork.com" for anything else |
| What it covers | "models for every potential interface that is currently recognized by Vega Runtime" |
That last row is the one that matters. They open-sourced the schema of the configuration. The runtime that executes it is closed, proprietary and available only as their SaaS.
Publishing the OOXML schema would not have made Microsoft Word open source. A vocabulary without an interpreter is not portability. It is a very detailed description of the cage.
For comparison: Magic is MIT. All of it. The runtime, the 40 plugins, the ~420 slots, the IDE, the frontend, the lot — at github.com/polterguy/magic, where it has roughly 1,193 stars against that repository's 3. Fork it, run it, sell it, never speak to me again. There is no key, no threshold, no competing-use clause and no four-year clock.
They are running two runtimes
Unqork's newer runtime is called Vega. The older one is Centauri. Their own documentation describes Vega as "a fully standalone second runtime that acts as an additive layer to Centauri."
So there are two engines, and customers are distributed across a migration between them. The company also moved the platform from Angular to React along the way.
I have opinions about big rewrites — I did one myself and wrote about deleting 46,000 lines of Angular in a weekend — so this is not a cheap shot at the decision. It is an observation about cost. Maintaining two runtimes means every fix is potentially two fixes, every component is potentially two components, and every customer eventually faces a migration they did not ask for and cannot opt out of, because they cannot host the old one themselves.
Which brings us to the exit.
There is no exit
| Unqork | Magic | |
|---|---|---|
| Self-hosted | No | Yes |
| On-premise | No | Yes |
| Air-gapped | No | Yes |
| Your own cloud account | No | Yes |
| Runtime source | Closed | MIT |
| Your application as portable files | No | Yes |
| Run it after you stop paying | No | Yes |
Unqork is SaaS only. Single-tenant VPCs on AWS or Azure, Kubernetes, MongoDB Atlas — a well-built managed platform, and genuinely a good one if managed is what you want. But there is no version you can run yourself, and your application is JSON in their document store, executable only by a runtime you cannot obtain.
Stack the three findings and look at what they add up to:
- Your application is stored in a format you cannot read without their IDE.
- The runtime that executes that format is closed.
- There is no deployment option outside their cloud.
That is not lock-in as a side effect of a business model. That is lock-in as an architecture. Every one of those three is a deliberate engineering decision, and each one independently prevents you from leaving.
Magic's answer to all three is the same answer: it is a file. Push the module to a GitHub repository in one click and the thing you push is readable Hyperlambda that runs anywhere the MIT-licensed runtime runs, which is anywhere with a container.
The price, and the thing I cannot put in the table
Unqork does not publish pricing. There is no pricing page, no tiers, no per-seat number, no starting-from figure. Publicly available descriptions say only that it is a subscription that scales with usage, feature requirements and platform capacity.
I am not going to invent a number for a comparison table. But the absence of the number is itself the finding, and anyone who has bought enterprise software knows exactly what it means: the price is whatever the account team concludes you can pay, it is negotiated annually, and it goes up.
Here is mine, and it is on the pricing page where you can check it without talking to anybody:
$100 per month for a hosted cloudlet. Not per seat. Not per table. Not per collection, per flow, per environment, per app, per API call or per anything else. Unlimited users. If $100 is too much, one copy-paste puts it on a $12 DigitalOcean droplet, or you self-host it on your own hardware for the cost of the hardware.
And we upgrade every single week
This is the operational half of the same argument, and it is where the two-runtime situation actually bites.
Unqork ships on a quarterly platform release cadence — Winter, Spring, Summer, Autumn — while simultaneously maintaining Centauri and Vega. Whatever landed in a given quarter, you wait for the next one, and you wait for it on whichever runtime you happen to be on.
AINIRO's hosted cloudlets are upgraded every single week. Not quarterly. Not when your account manager schedules a maintenance window. Every week, on one runtime, with no migration track and no legacy tier, because there is only one codebase and it is the same codebase whether you are hosted with me or running it yourself on a droplet.
When GPT-6 Astra shipped it was in Magic in days. When MCP became the thing everyone needed, same. That velocity is not a heroic effort on my part, it is a structural property of having one runtime, one artefact format and no enterprise release train to feed.
Where Unqork genuinely wins
The rule of this series is that this section has no rebuttals in it. They come after.
FedRAMP authorisation. This is the real moat and I will not pretend otherwise. A US federal agency can buy Unqork. It cannot buy "an MIT-licensed .NET application we host ourselves" without a year of paperwork first. If your procurement process requires that certification, this article is interesting but irrelevant to you, and you should buy Unqork.
Vertical component libraries. Eight years of insurance, wealth management, group retirement and capital markets components, built by people who understood those domains. Magic has none of that. You start from your schema.
Managed operations as a product. Single-tenant VPC per customer, zero-downtime patching, an SLA, someone to call at 3am. For an organisation with no platform team that is a genuine product, not merely hosting.
Non-developer usability. You can hand UDesigner to a business analyst and get something. You cannot hand Hyper IDE to a business analyst, and I would not suggest trying.
Reference customers and a talent pipeline. Goldman Sachs, Liberty Mutual, the cities of New York and Chicago. Unqork Academy turns out certified builders you can actually hire. Both of those are costs I carry on my side of this comparison, and both are real.
Why any of this matters more in 2026 than it did in 2020
In May 2026 Unqork announced UnqorkAI, positioned explicitly as the answer to "the chaos of enterprise AI code sprawl". The pitch is that their AI assembles vetted Smart Components and "never generates new or unvetted code to get the job done."
It is a coherent position and I understand its appeal to a risk committee. It is also, I think, exactly backwards, for two reasons.
First, their moat was the thing AI commoditises. Unqork's advantage was a large library of hand-built, human-vetted components, because building those was slow and expensive and they had a head start. That is precisely the category of work that large language models have made cheap. Meanwhile the thing they deliberately gave up — a readable, diffable, statically checkable text artefact — turned out to be exactly what AI-generated software needs in order to be governable.
Second, every serious AI development tool on earth converged on the same primitive: show me the diff. That is the entire governance story of AI-assisted engineering in 2026. Review the change, approve the change, or reject it. Unqork structurally cannot show you a diff, because their artefact does not diff and could not be read by the reviewer if it did.
There is a deeper version of this. "We vetted the components" is a process assurance — it is a claim about how a company behaves, and you either trust the company or you don't. Magic's equivalent is a decidable property: generated Hyperlambda executes as a tree where every node must bind to a whitelisted slot, so code that exceeds its permissions does not get discouraged by a system prompt, it throws at dispatch time. You can run a checker over a file and get back yes or no.
Those are not the same kind of claim, and in a governance conversation the difference is everything. I am confident enough in mine that there is a standing cash bounty on breaking it, which nobody has collected.
The decision rule
Buy Unqork if: you need FedRAMP or an equivalent certification today; you are in insurance, wealth or group retirement and their vertical library covers most of your domain; you have no platform team and want operations to be somebody else's problem entirely; or your organisation's procurement process cannot approve software that does not come with an enterprise vendor attached. These are legitimate reasons and no amount of architectural argument outweighs them.
Choose Magic if: you want to be able to read your own application; you want it under version control in a format where review means anything; you need to self-host, run on-premise or go air-gapped; you object to a price that is negotiated rather than published; or — the structural one — you expect AI agents to be building your backend, in which case you want an artefact they can read, write and be constrained by.
The single question that decides it: if your vendor disappeared tomorrow, would your application still run? If that question has an acceptable answer for you, Unqork is a good managed platform. If it doesn't, no feature list changes the outcome.
The fine print
Every claim about Unqork in this article comes from their own published material and was verified on the day of publication: the runtime specification repository and its README, licence, star count and contribution policy; their documentation on server-side module execution, proxy modules, Express View and the Calculator, Decisions, Initializer, Plug-In and Data Workflow components; the Winter 2024 and UnqorkAI press releases; their platform security and product overview pages; and their funding history. The quoted user criticisms come from public review aggregators, not from customers I have spoken to.
Two things I could not verify and have therefore not leaned on: Unqork's current revenue and headcount, which are available only as third-party estimates I would not want quoted back at me, and the internals of Smart Components, which as of today exist in marketing copy rather than documentation. Several documentation URLs also returned 404s during research, so some of the above is from indexed excerpts rather than pages I loaded myself.
And the obvious disclosure: I wrote Hyperlambda and I sell Magic hosting, so read the comparison rows accordingly. I have tried to make every factual claim checkable precisely because I am not a neutral party. Where I have been unfair, the repository and the documentation are both public — go and check, and tell me if I got something wrong.
For whatever it is worth as a credential: I have been writing software since I was eight years old, that is forty-four years now, and I am cited on microsoft.com.
Frequently asked questions
Is Unqork open source?
No. Unqork published its runtime specification — the JSON schema describing application configuration — under AGPLv3 in February 2024. The runtime that executes that configuration is closed and available only through their SaaS. The specification repository has 3 stars, 1 fork, two contributors who are both Unqork service accounts, and explicitly does not accept contributions. Magic is MIT licensed in its entirety, runtime included.
Can you self-host Unqork?
No. Unqork is SaaS only, deployed as single-tenant VPCs on AWS or Azure. There is no on-premise, air-gapped or bring-your-own-cloud option, and because the runtime is closed there is no way to run an Unqork application outside Unqork's infrastructure. Magic self-hosts anywhere a container runs.
How much does Unqork cost?
Unqork does not publish pricing. It is an enterprise subscription negotiated per customer, scaling with usage, features and platform capacity. Magic's hosted cloudlets are $100 per month, published, with no per-seat, per-table or per-application metering, and self-hosting is free under MIT.
Does Unqork run business logic in the browser?
By default, yes. Unqork modules execute in the browser in what they call Express View. Server-side execution is an opt-in module type, and their documentation additionally describes proxy modules whose purpose is to force-validate front-end data because a user can manipulate values through the browser console. Magic endpoints execute server-side only, with authorisation enforced at the runtime on every invocation.
Which is older, Unqork or Hyperlambda?
Hyperlambda dates from 2013 and the current Magic codebase from 2019, ported from the older Phosphorus Five. Unqork was founded in 2017. Hyperlambda predates Unqork by four years.
How often is Magic Cloud upgraded?
AINIRO's hosted cloudlets are upgraded every week. Unqork ships quarterly platform releases while maintaining two runtimes, Centauri and Vega, with customers distributed across a migration between them.
Related reading
- Magic vs Directus: An Honest Feature Matrix
- What Is Hyperlambda and How Does It Work?
- Zero Hallucination Code Generation: A Vocabulary Your AI Cannot Escape
- Why Secure AI Code Execution Requires Runtime Whitelisting, Not Prompt Filtering
- I Can Probably Recreate Your 25 Year Old Legacy System in 20 Minutes
- Magic Cloud on DigitalOcean — One Copy-Paste