Lusandbox

If you have used Express.js, Koa, or Sinatra, Wapka’s Lua framework will feel immediately familiar. The syntax is designed to be recognizable — on purpose. A quick tour local app = framework() app:get("/", function(ctx) return ctx:html("<h1>Hello from Lua</h1>") end) app:get("/api/users", function(ctx) local users = api.users.list({ limit = 50 }) return ctx:json(users) end) app:post("/api/contact", function(ctx) local name = ctx.body.name local email = ctx.body.email api.dataset.create("messages", { name = name, email = email }) return ctx:json({success = true}) end) Route definitions. Request parameters. Database queries. JSON responses. Standard web development patterns — running inside a sandboxed Lua environment via PHP LuaSandbox. ...

Every platform makes a bet on its technology stack. Wapka’s bet was Lua. Here’s why it wasn’t just a good choice — it was the only choice that made the entire platform economically possible. The problem: multi-tenant code execution Wapka lets users write server-side scripts. That means arbitrary code from thousands of users runs on shared infrastructure. In most languages — Node.js, Python, PHP — running untrusted user code safely at scale requires containerization. Docker. MicroVMs. gVisor. These add memory overhead, startup latency, and cost. ...

The numbers tell the story. A Node.js process consumes roughly 30 megabytes of memory. A Python process: 20 megabytes. A Lua state inside LuaSandbox: 1 to 5 kilobytes. That three-order-of-magnitude difference is why Wapka can offer server-side scripting for free. The runtime economics When you let thousands of users run server-side code on shared infrastructure, the cost of each execution matters exponentially. At scale, memory and CPU are the dominant factors. ...