Magic Cloud: self-hosted full-stack apps and MCP tool servers from plain English

The gap Magic Cloud fills for backend engineers

Most AI app builders generate a frontend and hand the backend to a hosted service. Magic Cloud takes the opposite position: the README describes it as an open-source alternative to Lovable, Bolt and Replit that gives you the whole backend, and the comparison table lists database, API, auth, RBAC and jobs as included rather than delegated. The intended user is an engineer who already has a database, possibly a legacy one, and wants a secured CRUD API over it without writing controllers by hand. The secondary user is someone building an AI agent that needs to call real endpoints under real access control, not a sandboxed toy. The project is written in C#, licensed MIT, and the default branch is master. The last push was on 2026-09-09, and the most recent release that day was v23.5.19, described as security patching in download referenced files. That pattern, small frequent releases with security fixes, is worth noting when you plan an upgrade cadence. Magic Cloud is not a library you import. It is a server you run, and everything else follows from that.

Hyperlambda, the sandbox and the AST that cannot hallucinate functions

The core mechanism is Hyperlambda, a language the README describes as running sandboxed with no file system access outside its sandbox. Instead of compiling C# for every endpoint, you write or generate Hyperlambda, and the runtime executes it. The RBAC system can whitelist individual functions, which means the server can accept code as input and restrict which invocations are permitted at execution time. That is the part worth pausing on: most systems restrict who can submit code, while Hyperlambda restricts what the code can call once it is running. The AI generation layer builds on this. According to the README, Magic runs a proprietary LLM that generates an abstract syntax tree rather than text, and the output is rejected if it contains functions that do not exist. The claim is narrow and stated as such: the generator cannot return hallucinated function invocations, but like any LLM it can still write logically wrong code. That distinction matters if you are evaluating this for anything security-sensitive. A generated endpoint that calls only real, whitelisted functions can still compute the wrong result. The README also says the vocabulary can be restricted, which is what lets agents grow their tool space on demand without widening the attack surface. There is a standing bounty mentioned in the README, $100 for a severe backend security bug and another $100 for exploiting the natural language API, which has accepted arbitrary public input for three months at the time of writing.

Running Magic Cloud from the published Docker Compose file

The README's quickest path is a single curl piped into docker compose. The repository also ships a docker-compose.yml with two services, backend and frontend, and named volumes for etc, data, config and modules. The backend exposes port 4444 and the frontend maps port 80 inside the container to 5555 on the host. The frontend service declares depends_on with condition: service_healthy, so it waits for the backend health check rather than just the container start. That health check polls http://localhost:4444/magic/system/healthz every 30 seconds with 5 retries and a 30 second start period. Both services cap their json-file logs at 10m with 3 files, which is a deliberate choice to stop a chatty install from filling the disk.

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

After the containers come up, the README says to open localhost:5555, point it at localhost:4444, and log in with root / root. Changing that default credential is the first thing to do on anything reachable, and the README does not document a forced rotation. If you prefer to run the checked-in file instead of the hosted one, the repository's docker-compose.yml pulls servergardens/magic-backend:latest and servergardens/magic-frontend:latest. Pinning to a specific tag rather than latest is left to you; the README does not discuss tag pinning.

The API Wizard and the endpoint generator in practice

The README's walkthrough image shows the API Wizard turning the chinook database into 54 secured REST endpoints, invoking one, and then extending it with AI. The dashboard sidebar is described as the whole platform: Hyper IDE for editing, running and replaying any file on the server, Playground for executing Hyperlambda without saving, SQL Studio for querying and designing databases, and the Endpoint Generator for turning tables into secured CRUD endpoints. The Endpoint Generator also imports third-party APIs from their OpenAPI specifications, so pasting a Swagger URL gives you typed endpoints wrapping Stripe, GitHub or Slack. The workflow claim is that once you save the code you can test it, with no deployment or publish step. That is the concrete difference from a framework where you edit, build, restart and then curl. Whether it holds for your setup depends on how much of your logic lives outside Hyperlambda. If you need to call into an existing C# library that is not exposed as a Hyperlambda function, the no-build promise stops applying at that boundary. The README does not describe a supported path for that case.

MCP support and the token saving claim

The mcp plugin is the feature that distinguishes Magic Cloud from other generators. Install it, point Claude Code, Cowork or OpenAI's Codex at your cloudlet, and every HTTP endpoint in your modules folder becomes a tool the agent can invoke. The README states that in the project's own measurements this cuts token consumption by roughly 80 percent, and links to a savings calculator. That number comes from the project, not from an independent test, and the README does not publish the methodology behind it. Treat it as a claim to reproduce on your own endpoint set rather than a property of the software. The mechanism itself is straightforward: fewer tokens are spent describing tools because the tool surface is derived from endpoints that already exist and already carry documentation. The dashboard shows the cloudlet's MCP URL at the top, which is how you hand endpoints to an MCP-capable agent. The README also notes the reverse direction: the Chatbot Wizard crawls a website, turns what it finds into training data, and produces an embeddable chatbot grounded in that content. Both directions depend on the same generated endpoint layer, so a messy API surface produces a messy tool surface.

Where Magic Cloud is the wrong tool

Hyperlambda is the limitation. If your team writes C# and expects to keep writing C#, adopting Magic Cloud means a second language in the critical path, and the README does not claim Hyperlambda replaces C# for general development. The generation layer is also proprietary even though the platform is MIT licensed. The repository is open, the LLM that generates Hyperlambda is not, and the README describes it as "our own proprietary LLM." If your organisation cannot send prompts to a third-party generator, the AI features are not usable as described, and what remains is a Hyperlambda runtime with an endpoint generator. The security model is unusual enough to require review rather than assumption: accepting code as input and restricting it by whitelisting functions is a real design, but it is a design you should read the code to trust, and the README's bounty offer is an argument, not an audit. Finally, the README does not document rollback for generated endpoints. If a generation step produces something wrong, the README's replay feature in Hyper IDE is the closest thing to an undo, and that is not the same as a versioned migration path.

Magic Cloud compared with n8n and Zapier

The README's own comparison table puts Magic Cloud against Lovable and Bolt on one side and n8n, Zapier and Make on the other. The difference in approach is the execution model. n8n and similar tools interpret workflows described in JSON, XML or YAML. Magic Cloud runs Hyperlambda on a compiled .NET runtime. The README states that in the project's measurements Hyperlambda is roughly 20 times faster than FastAPI or Flask, around 50 times faster than LangChain, and 100 to 1,000 times faster than graphical workflow tools, and that Hyperlambda solutions are broadly on par with C# and Entity Framework. Those are vendor measurements with no published harness, so the useful takeaway is the architectural one: a compiled runtime avoids the parse-and-dispatch cost that a workflow interpreter pays on every step. If your workload is a few hundred webhook calls a day, that difference is irrelevant and n8n's visual editor is easier to hand to a non-engineer. If you are running database-backed agents at volume, the runtime choice starts to matter. The other difference is scope. n8n gives you workflows; Magic Cloud gives you workflows plus the database, the auth layer and the API the workflows call.

Licence, upgrades and what maintenance actually costs

The repository is MIT licensed, which permits commercial use and modification. The licence covers the code in the repository. It does not cover the proprietary Hyperlambda generator, and it does not cover any hosted service the project offers. The README's own comparison table lists vendor lock-in as none for Magic Cloud, and that is accurate for the runtime you deploy: the Docker images and the Hyperlambda files are yours to keep running. It is less accurate for the generation step, which depends on a service the project controls. Upgrades are frequent. Three releases landed between 2026-09-05 and 2026-09-09, covering BOM handling in the CSV slot, migrating AI function system messages during startup, and a security patch. The startup migration in v23.5.17 is the kind of change that can surprise you if you pin an older image and then move forward, because it rewrites stored AI function definitions. The docker-compose.yml uses the latest tag for both images, so a restart can pull a new version without warning. If you care about reproducible deployments, pinning tags is a change you make to the file yourself. The last push to the repository was on 2026-09-09.

Editorial conclusion

Adopt Magic Cloud if you need a self-hosted backend with role-based access control and want every endpoint exposed as an MCP tool, and you are willing to learn Hyperlambda rather than write C#. Skip it if your team will not accept a proprietary generator LLM or a non-mainstream language in the critical path. Before committing, verify the plugin store contents and confirm the mcp plugin is available for your release, since the token saving claim depends on it.

Frequently asked questions

Official sources

1. License: MIT
2. polterguy/magic on GitHub
3. Project website
4. README
5. Releases