Magic Cloud: Hyperlambda, the MCP Plugin, and What the README Leaves Unstated
Instant SECURE Full Stack Apps and AI Agents
At a glance
- What is it?
- Magic is an MIT-licensed C# platform that generates database-backed REST APIs and AI agents from plain English, running on your own hardware. The interesting part is not the generator but the execution model underneath it: a sandboxed language whose function vocabulary can be whitelisted per role.
- Who is it for?
- Adopt Magic if you have an existing MySQL, PostgreSQL, SQL Server or MariaDB schema and want a secured CRUD API over it without writing the controller layer, or if you want your own endpoints exposed as MCP tools to Claude, Cursor or Codex. Do not adopt it if you need a documented scaling story, a published security audit, or if your team cannot read Hyperlambda.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Who Magic is aimed at, and who it is not
The README lists the target jobs plainly: full-stack business apps (CRM systems, admin panels, booking systems, internal tools), database-driven AI agents, chatbots grounded in crawled site content, CRUD APIs over legacy databases, wrappers around third-party APIs imported from OpenAPI or Swagger specs, MCP tool servers, scheduled background jobs, and static sites served next to their APIs. The common thread is a database you already own and a backend you would otherwise hand-write. The comparison table puts Magic against Lovable and Bolt on one axis and n8n, Zapier and Make on another, claiming self-hosting, an included backend, and no deploy step before you can test. That positioning tells you who this is for: a developer or small team with a schema in hand, a server to run on, and no appetite for a third-party BaaS in the request path. It is not for someone who wants a managed service to disappear into. The moment you run the Docker Compose file you own the database, the auth, the RBAC configuration and the upgrade path.
Hyperlambda is the actual product, not the generator
The headline feature is natural-language app generation, but the mechanism that makes it worth reading about is Hyperlambda. Magic runs Hyperlambda in a sandbox with no file system access outside that sandbox, and the RBAC system can whitelist individual functions. The README's claim is that this lets a server accept code as input and execute it without knowing where the code came from, because invocations are restricted at the execution level rather than the parsing level. That is a different shape from the usual approach of validating a script before running it. It also explains the LLM story: the Hyperlambda Generator produces an AST rather than text, and the output is analysed and rejected if it invokes functions that do not exist. As the README puts it, the generator cannot return hallucinated function invocations, though it can still write logically wrong code. Read that sentence carefully, because it is the honest version. Structural validity is guaranteed. Intent is not. A generated endpoint can be syntactically perfect and still expose the wrong table to the wrong role.
Getting it running: the two ports and the default credentials
The README gives a one-line start: curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up. The dashboard then lives on localhost:5555 and you point it at the backend on localhost:4444, logging in with root / root. Those defaults are the first thing to change. Piping a remote Compose file into docker compose means you are executing whatever that URL returns at the moment you run it, so fetch the file, read it, and run it from disk if you care about reproducibility. The rest of the workflow is dashboard-driven rather than CLI-driven: the API Wizard points at a database and generates secured REST endpoints (the README's walkthrough uses the chinook database and reports 54 endpoints), the Endpoint Generator turns tables into secured CRUD endpoints, SQL Studio handles queries and schema design, Hyper IDE edits and runs files on the server, and the Playground executes Hyperlambda without saving it first. The claim that matters operationally is that once you save the code you can test it, with no deployment or publish step. For a single cloudlet that is a real reduction in cycle time. It also means the running server is the development environment, which is a configuration you have to think about before it faces anything public.
The MCP plugin and the token-saving claim
Install the mcp plugin, point Claude Code, Cowork or OpenAI's Codex at the cloudlet, and every HTTP endpoint under your modules folder becomes a tool the agent can invoke. That is the whole integration, and it is the most immediately useful thing in the repository for anyone already using an MCP client. The README also states that in the project's measurements this cuts token consumption by roughly 80%, with a link to a savings calculator. Treat that number as a vendor measurement, not an independent benchmark. The mechanism is plausible on its face: if an agent calls a typed endpoint that returns only the data it needs, it avoids reasoning through a long tool description or a broad query result. But the figure depends entirely on what you are comparing against, and the README does not state the baseline. The same caution applies to the performance section, which reports Hyperlambda as roughly 20x faster than FastAPI or Flask, around 50x faster than LangChain, and 100 to 1,000x faster than graphical workflow tools, with parity to C# and Entity Framework. The stated reason is that it runs a compiled .NET runtime instead of interpreting JSON, XML or YAML. That reasoning is sound. The multipliers are still the project's own.
Where the documentation stops short
Several things a reader would want before adopting are simply not in the material. There is no deployment topology guidance: nothing about running more than one cloudlet, sharing a database between instances, or where session state lives. There is no published security audit, only a bounty offer of $100 for a severe backend bug and another $100 for exploiting the natural language API, which the README says has accepted arbitrary public input for three months without a successful exploit. A bounty is a signal of confidence. It is not the same as a review. There is no migration guide for the Hyperlambda you generate, and no discussion of what happens when the generator's output drifts from what you hand-edited. There is also no stated compatibility matrix beyond the .NET 10 badge, so the supported SQL Server, MySQL, PostgreSQL and MariaDB versions are unconfirmed. None of this is disqualifying for an internal tool. All of it matters if the cloudlet is going to hold customer data.
The wrong tool for stateless, high-scale services
Magic bundles a database layer, an auth system, RBAC, a scheduler, a file server and a code execution sandbox into one process. That is the point, and it is also the constraint. If your workload is a stateless service behind a load balancer, where any instance can handle any request and nothing is pinned to a host, this architecture fights you. The same applies if your organisation already has a hardened API gateway and a policy that no service executes code submitted at runtime, regardless of sandboxing. The whitelisting feature is a genuine mitigation, but it is a mitigation for a capability most teams have deliberately removed from their stack. And if your team writes Python or TypeScript and has no intention of learning a language whose semantics live in a separate site, the generation feature only gets you the first draft. Everything after that is Hyperlambda maintenance.
How it differs from a workflow tool like n8n
The nearest comparison in the README's own table is n8n, and the difference is worth stating precisely. n8n interprets a workflow graph serialised as JSON: you assemble nodes, the engine walks the graph, and each node's behaviour is defined by its implementation. Magic compiles to a .NET runtime and executes Hyperlambda, which the README describes as an AST-based language. The practical consequences are the sandbox and the function-level RBAC whitelisting, which a graph interpreter does not offer in the same form, and the absence of a publish step between editing and testing. The trade-off runs the other way too. A workflow tool's graph is inspectable by anyone who can read a diagram, and its node library is a known quantity. Hyperlambda is a language, and a language has to be learned. If your integration work is mostly gluing SaaS APIs together on a schedule, n8n's model is a better fit. Magic's advantage appears when the logic is database-centric and you want the API, the auth and the agent tools to come from the same definition.
Upgrade cost and the MIT licence in practice
The release cadence visible in the material is fast and patch-oriented: v23.5.17 migrates AI function system messages during startup, v23.5.18 ignores BOM characters in the CSV slot, v23.5.19 patches security in downloading referenced files. Three releases in four days, each a small fix. That pattern is good for responsiveness and awkward for operators, because it means the project expects you to move. A startup migration in v23.5.17 is the kind of change that can alter stored state, so pinning a version and ignoring it for a year is not a neutral choice here. The MIT licence removes the legal friction: you can modify, self-host and redistribute, and there is no open-core split described in the material. What MIT does not give you is any warranty or support obligation from the maintainer, and the README's bug bounty is a personal offer rather than a contractual commitment. If you need a vendor to escalate to, this project does not provide one. Budget for reading release notes before each upgrade, and test the startup migration path on a copy of your database first.
Editorial conclusion
Adopt Magic if you have an existing MySQL, PostgreSQL, SQL Server or MariaDB schema and want a secured CRUD API over it without writing the controller layer, or if you want your own endpoints exposed as MCP tools to Claude, Cursor or Codex. Do not adopt it if you need a documented scaling story, a published security audit, or if your team cannot read Hyperlambda. Before committing, verify three things yourself: that the sandbox boundaries match your threat model, that the vocabulary restriction you configure actually rejects the function invocations you expect it to reject, and that the version you pin is recent enough to include the v23.5.19 fix to "download referenced files".
Community notes