Best free AI app builder, ranked by what the free tier actually gives you
Most lists rank these tools by what apps you can build. That ignores the part that matters: what runtime each "free" tier actually hands you. A static HTML preview behind a signup wall is not the same product as a real Linux VM with Postgres, an email API and a private repo. This guide ranks the field on infrastructure, not feature lists.
The honest definition of "free"
Open any of the popular tools that come up for this topic and look at what the free tier hands you. Most fit one of three buckets:
- Static preview: AI generates HTML or a single-file app, you can look at it but not really run it against a database.
- Shared playground: A browser-tab-only sandbox with an in-memory KV store or local SQLite, no networking out.
- Trial: Real infrastructure, unlocked only after email, OAuth, and usually a credit card.
mk0r is in a fourth bucket. The free tier hands an anonymous visitor a real Linux VM with provisioned Postgres, email and source control before the first prompt finishes. The rest of this page documents that, file by file, port by port, so you can verify it before you trust the claim.
What an anonymous visitor receives
The diagram below traces the actual data path. A client-side UUID hits the Cloud Run frontend, the frontend pulls a warm sandbox out of the Firestore pool, and inside that sandbox four external services have already been provisioned.
Free-tier provisioning flow
The hub is the E2B sandbox spun up from template mk0r-app-builder. The destinations on the right are the things every other free tier makes you sign up for. Here they land in your sandbox before you have an account.
The numbers come from one config file
When someone says "free" for an AI app builder, the right follow-up is "free of what?" Here is the answer for mk0r, in the file that defines the sandbox shape:
Four cores. Four gigabytes. The same template id every visitor boots. There is no "starter" tier that capped you at 1 vCPU and a 100 MB heap; the free tier is the tier.
Boot sequence: six services, no signup gate
The Dockerfile's last EXPOSE line lists six ports. The startup script in docker/e2b/files/opt/startup.sh starts each one in order. Tail the boot log of any anonymous session and you see this:
Anchor fact, in one sentence
The same E2B template ( 2yi5lxazr1abcs2ew6h8 ) boots a 4 vCPU / 4 GB sandbox, exposes ports 3000, 3001, 3002, 5173, 5901 and 9222, and runs provisionServices(sessionKey) from src/core/e2b.ts:1346 on the first message, wiring Neon, Resend, GitHub and PostHog into /app/.env before the agent writes its first line of code. No vendor on the lists you have already read offers any of those four out of the box on the free tier.
What happens between "press Enter" and "app rendered"
You type one sentence and press Enter
No signup form, no onboarding. The session id is a UUID generated client-side in your browser and stored in sessionStorage.
Source: src/app/page.tsx
getOrCreateSession matches you to a warm VM
computeSpecHash() returns the static template id, which is the cache key the Firestore-backed pool uses to find a ready sandbox. You attach to a VM that already finished `npm install`.
provisionServices runs in parallel
Inside getOrCreateSession, mk0r kicks off provisionPostHog, provisionResend, provisionNeon, provisionGitHub at the same time. Most settle in a couple of seconds.
Wired at src/core/e2b.ts:1346
buildEnvFileContent writes /app/.env
DATABASE_URL, RESEND_API_KEY, RESEND_AUDIENCE_ID, VITE_POSTHOG_KEY, VITE_POSTHOG_APP_ID, GITHUB_REPO and the rest land in the env file before the agent's first tool call.
Agent edits /app/src and renders in Chromium
Vite picks up the change, the agent navigates to localhost:5173 through Playwright MCP, reads the DOM, watches the console, and only surfaces the preview to you after the page actually renders.
The same surface area, side by side
| Feature | Typical free tier | mk0r |
|---|---|---|
| Account required to start | Yes (email + verification) | No |
| Runtime given to your app | Static preview or shared sandbox | 4 vCPU / 4 GB Linux VM, isolated per session |
| Database on free tier | None or local-only | Real Neon Postgres, provisioned on first message |
| Email sending on free tier | Disabled or paid-only | Per-app Resend API key, no setup |
| Source control on free tier | Export ZIP at best | Private GitHub repo at m13v/mk0r-app-<slug> |
| AI verifies in a real browser | No, ships raw output | Chromium + Playwright MCP on port 3001 |
| Public ports exposed to your app | 1 (preview) | 6 (proxy, MCP, ACP, Vite, VNC, CDP) |
| Residential IP for outbound traffic | Datacenter IP | Bright Data residential proxy on 127.0.0.1:3003 |
Based on publicly available free-tier limits as of April 2026 across Bolt, Lovable, Replit, Base44, Bubble, Jotform, Taskade, Figma Make, Blink and Dyad.
What you get, broken out
The cards below are the contents of /app/.env translated into English. Every value resolves to a real, pre-provisioned resource.
4 vCPU, 4 GB RAM, 1-hour ceiling
Defined verbatim in docker/e2b/e2b.toml: cpu_count = 4, memory_mb = 4_096. E2B_TIMEOUT_MS in src/core/e2b.ts = 3,600,000. Every anonymous visitor gets the same shape.
Real Postgres
Neon project provisioned via console.neon.tech/api/v2 against org-steep-sunset-62973058, with DATABASE_URL written into /app/.env before the agent reads it.
Per-app Resend key
provisionResend mints a restricted API key scoped to a single audience. The agent can send transactional email out of the box without you handling secrets.
Private GitHub repo
provisionGitHub creates m13v/mk0r-app-<slug>. Every commit the agent makes lands there, so the code follows you out of the sandbox.
PostHog wired in
Shared project key with a per-app appId set as a group property, so events from your generated app are isolated without you registering.
Six ports exposed, not one
EXPOSE 3000 3001 3002 5173 5901 9222 in docker/e2b/e2b.Dockerfile. Public proxy, Playwright MCP, ACP bridge, Vite, VNC, Chrome DevTools. The visible preview is the smallest part of what runs.
Tools we benchmarked the free tier of
The list of names everyone else mentions in roundups. Each one was opened in a fresh browser to verify what the free tier actually allows before signup.
Why this matters for your generated app
The infrastructure question is not academic. It decides the kind of app you can finish without leaving the tool. A free tier that gives you a Postgres connection string lets the agent run real migrations, store user data, and test against a database. A free tier that gives you a Resend key lets the agent ship transactional email. A free tier that gives you a GitHub repo means the code can leave the tool with you.
Without those, "built an app with AI" collapses to "rendered a page." The tools at the top of most listicles are good at rendering pages. They are bad at handing you the rest. mk0r treats the rest as the point and folds it into the free tier rather than the upgrade path.
You can verify any of this without an account. Open mk0r.com, type a prompt, and inspect /app/.env inside the running sandbox via the agent's shell. Every value listed in this guide will already be there.
Want a walkthrough of the free-tier infrastructure?
Book 20 minutes. We will boot a sandbox in front of you, dump /app/.env, and run a migration against the provisioned Postgres, all without an account.
Frequently asked questions
Why measure free tiers by infrastructure instead of by app type?
Because the AI part is mostly the same model behind every tool. What changes between vendors is what your generated app can actually run against. A tool that gives you a static HTML preview tied to a paid account is not equivalent to one that gives you a real Linux VM with a Postgres database and an email API. If the goal is shipping something, the runtime matters more than the prompt.
What exactly does mk0r give an anonymous visitor on the free tier?
An E2B sandbox built from template id 2yi5lxazr1abcs2ew6h8. The template is defined in docker/e2b/e2b.toml with cpu_count = 4 and memory_mb = 4_096. The Dockerfile's last EXPOSE line is `EXPOSE 3000 3001 3002 5173 5901 9222`, so six ports are live: the public proxy on 3000, Playwright MCP on 3001, the ACP bridge on 3002, the Vite dev server on 5173, websockify-wrapped VNC on 5901, and Chromium DevTools Protocol on 9222.
Are the database, email and repo really provisioned for free, no email?
Yes. src/core/service-provisioning.ts exports provisionServices(sessionKey) which calls Neon's API at console.neon.tech/api/v2 and creates a fresh Postgres project under org-steep-sunset-62973058, mints a per-app restricted Resend key, attaches the visitor to the shared PostHog project, and creates a private GitHub repo at m13v/mk0r-app-<slug>. The result is written into /app/.env. The wiring is at src/core/e2b.ts line 1346, inside getOrCreateSession. You never typed an email and the agent already has a DATABASE_URL it can run real migrations against.
Doesn't every tool give you a database on the free tier?
No. Most free-tier app builders give you either a static preview, an in-browser SQLite shim, or a key/value store tied to a paid plan. The ones that do offer a real database make you sign up, link a payment method, or both. mk0r's free tier provisions a real Neon Postgres on first message, no email required, and the connection string is already in your environment when the agent starts writing code.
How fast does the sandbox boot?
The template is pre-baked, so cold boot from the snapshot is around 2 to 3 seconds. The mk0r VM pool keeps a Firestore-backed pool of warmed sandboxes so you usually attach to one that is already running. computeSpecHash() in src/core/e2b.ts returns a static `e2b-template-2yi5lxazr1abcs2ew6h8` string, which is the cache key the pool uses to match you to a ready VM.
Why does mk0r run Chromium and Playwright inside the VM?
Because AI-generated code looks correct in isolation but fails at render time: a missing import, a misnamed CSS variable, a hook called conditionally. Most other free builders skip browser verification and hand you the raw output. mk0r boots Chromium on Xvfb display :99 with `--remote-debugging-port=9222`, exposes it via @playwright/mcp on 3001, and lets the agent navigate the running app, read the DOM, and catch console errors before you ever see the preview.
How long does the VM stay up?
E2B_TIMEOUT_MS is set to 3,600,000 in src/core/e2b.ts, so each session gets a 1-hour ceiling. Sessions can be paused and resumed via sandbox.pause() + Sandbox.connect(), and the active session map is mirrored into Firestore under the `app_sessions` collection so a tab refresh or Cloud Run cold start does not lose your work.
What about residential IP for outbound traffic from the generated app?
The Dockerfile installs a Bright Data upstream proxy at /opt/brd-proxy.js. Chromium launches with `--proxy-server=http://127.0.0.1:3003`, with `--proxy-bypass-list='<-loopback>;localhost;127.0.0.1'` so internal services are direct. When the agent calls enableResidentialIp(), the upstream credentials are written to /run/brd.conf and Chromium traffic routes through a real residential IP instead of the E2B datacenter range. None of this is on the free tier of any other tool we benchmarked.