Two prompts into your AI agent.
One production app. HTTPS included.

Appximo compiles a JSON schema into a complete multi-tenant backend — REST + GraphQL + interactive docs + admin panel + a generated back-office — as one static Go binary on a PostgreSQL you control. Prompt 1 puts the engine on your machine. Prompt 2 takes your agent (Claude Code, Cursor, Copilot…) from an idea in one sentence to a running app, and to a real domain with HTTPS when you say so.

⏱ Measured, both by recording: the app is  running at 0:22 below · a fresh agent reached the fully green checklist in  1m53s
appximo new — one real run, unedited pause · rewind · change speed · copy the text
One sentence → a running, multi-tenant app. A real recording, played by the real player: press space to pause anywhere, drag the bar to rewind, select the text to copy it. Dead air is capped at 3 s here so you are not watching the model think for fourteen — on the real clock the schema validates at 0:17, the app is running and verified at 0:22, and the take runs to 0:47 because it ends with the graceful Ctrl+C. The untouched recording ships in the repo.
Stop here: 0:06 the AI schema validates on the first try 0:11 the app is running — request verified, URLs printed
Get the two prompts ↓ Read the guide
Go 1.25, no CGO Schema-per-tenant isolation Your own PostgreSQL Apache 2.0 · self-hosted
Status, honestly: the code is production-verified; four apps run on it in production today — two of them built end-to-end by third parties (one is a 32-resource recruiting platform you can open: atina.appximo.com). The repository is public, binaries + checksums are released, the Go module is fetchable, the Docker image is published. Version note: every release from v0.1.5 (2026-08-08) onward ships appximo prompt, up, new and the /app back-office, so the install prompt below leaves you a binary with everything this page describes.

Get started

Two prompts, pasted in order

Nothing to install by hand, no wizard. Each block below is a complete prompt for the coding agent you already use. Paste the first one, wait for it to report the version it installed, then paste the second.

1
Step 1 · once per machine

Install Appximo

This prompt does exactly one thing: leave the right binary on your PATH — a fresh install, or an update of the old copy already there (the common case, and the one that later fails in ways that read like typos). It ends by proving the result with a three-command checklist.

Preview — what the agent will run for you
Preview — what the agent will run for you

You don't type those. The prompt below is platform-agnostic — the agent detects your machine, picks its own block, verifies the checksum and replaces the old binary in place.

Prompt 1 · install

Already have a binary? It prints this prompt itself: appximo prompt --install

then, once the agent tells you which version it installed
2
Step 2 · once per app

Build your app

Replace one line with your idea and paste. The agent asks its single question block up front (Postgres? production?), then works alone against an executable checklist. It checks the engine from Step 1 first and refuses to proceed on a missing or stale binary — which is why the two prompts are separate.

Prompt 2 · build

Replace the highlighted MY IDEA line, paste, answer the one question block. It prints itself too: appximo prompt

The same path, typed by you

The manual path is the ground truth and the net — every command verified against a real engine: QUICKSTART.md

What happens

After the second paste, in three moves

You watch; the agent works. Every move is gated by a checklist item it has to prove with a real request, so it knows when it is done and you are never asked mid-way.

1

It writes the schema from your idea

The engine prints its own grammar (appximo spec), so nothing is invented. The agent then self-corrects in a loop against appximo validate --json until the schema is valid and warning-free — a machine-readable oracle instead of guesswork.

2

Your app runs

appximo up boots everything in one command — Postgres, secrets, your tenant, the first admin — and prints the URLs, the one-time credentials and a curl that already works. You get /app (a back-office generated live from your API's contract), /docs, /admin and /editor, with no code written.

The /app generated back-office on v0.1.13: a list of 112 records with the footer — page 1 of 8, 15 of 112, the engine's query time
/app — generated from the OpenAPI contract at runtime: forms, validation, state machines, permissions, and an honest footer (the exact total, the engine's own query time from its Server-Timing header). Zero screens written. v0.1.13.
3

It publishes with HTTPS

Say yes to the production question and give it a domain + a VPS. The same prompt drives the one-command installer — native PostgreSQL, a hardened systemd unit, Caddy with automatic Let's Encrypt — on an empty box or next to what already runs there (--app namespaces everything). The final checklist is a valid certificate, a 201 over HTTPS, and a service that survives reboots.

petfriendly.appximo.com — a production Appximo app served over HTTPS with a Let's Encrypt certificate
A real deploy of exactly this path — petfriendly.appximo.com, Let's Encrypt, one of the four production apps linked below.

Under the hood

The whole backend is one file you can read

No handlers, no models, no migration files. The schema compiles at boot — routes, SQL, validation, RBAC and docs are derived from it, and each tenant's tables are created when the tenant registers.

The first local run is one command: appximo up resolves Postgres (yours, or Docker), writes and loads the secrets, registers your app with its schema, creates the first admin, and prints the URLs, the credentials and a curl that already works — including /app, a back-office generated live from your API's own contract. appximo new "<your idea>" does the same with the schema AI-generated from one sentence. The three steps below are what it orchestrates.

1

Declare

Types, rules, lifecycles, relations and roles — a closed, validated vocabulary. Typos are load errors that list the valid keys, never silently dead config.

{
  "$schema": "https://appximo.com/schema/v1",
  "version": "1",
  "name": "todo-api",
  "resources": {
    "tasks": {
      "fields": {
        "title":  { "type": "string", "required": true },
        "status": { "type": "string", "enum": ["open", "done"], "default": "open" }
      }
    }
  },
  "rbac": { "roles": {
    "admin":  { "resources": "*", "actions": ["*"] },
    "viewer": { "resources": ["tasks"], "actions": ["read"], "fields": ["id","title","status"] }
  } }
}
2

Boot

Three env vars, one command. On an empty database the engine bootstraps its own control plane — no SQL to apply.

DATABASE_URL=… JWT_SECRET=… ADMIN_KEY=… \
  ./appximo serve --schema schema.json --port 8080
3

Call it

Register a tenant (its isolated Postgres schema is created at that moment), mint a token, and the API answers — with typed filters, keyset pagination, GraphQL, SSE, aggregation and a 422 that lists every invalid field at once.

curl -X POST localhost:8080/api/tasks \
  -H "Authorization: Bearer $TOKEN" -H "Host: acme.localhost" \
  -d '{"title":"ship it"}'
# → {"id":"d29325e1-…","title":"ship it","status":"open"}

The 90 % is declared

CRUD, filters, relations with real foreign keys, state machines enforced inside the UPDATE, RBAC down to rows and fields, migrations with a destructive-approval gate — all from the schema.

The 10 % is plain Go

Custom routes run in-process, inside the same transaction as the generated CRUD, with the same RBAC re-evaluated. A checkout that locks stock, writes the order and its lines commits as one unit.

The frontend rides along

Config.Static serves your SPA from the same binary and origin — no CORS, no second deploy. The live shop below is exactly that.

The AI path

Your agent builds it. The engine prints the contract.

Three commands print the full agent-facing documentation — schema grammar, backend handlers, frontend contract. Paste them into the Claude Code or Cursor you already pay for; the agent generates and then self-corrects against a machine-readable oracle. Zero product API cost.

appximo prompt         # THE prompt: idea → production, one paste (start here)

appximo spec           # the schema grammar (the declarative 90 %)
appximo backend-spec   # custom Go handlers, hooks, auth, jobs
appximo frontend-spec  # the API contract a UI consumes, errors → screens
appximo backoffice-spec# a CRUD admin generated from /openapi.json
appximo quickstart     # OPERATING it: tenants, users, migrate, production
appximo specs          # all five in one stream (one paste = the whole contract)

appximo validate --json app.json   # the oracle: path/rule/expected/fix per error

Tested cold: an agent with NO repo access built a working app

A fresh agent was given only four printed documents — the three specs plus the project README — and the CLI; no engine source. It shipped “Cancha Ya”, a court-booking app: schema with a state machine and per-resource RBAC, a custom Go route computing a price inside the engine's transaction, and an embedded frontend. The schema validated on the first attempt; the Go compiled on the first attempt; browser e2e at mobile viewport passed 9/9 with zero console errors. Its diary records zero blockers — “nothing exceeded 20 minutes without a way out.”

The built-in loop, measured

appximo ai-generate "<description>" runs the same loop with a cheap hosted model: on a 120-case stratified corpus, ~90 % of schemas valid on the first try, 100 % convergence, ~$0.006 per schema. And a schema that is valid but wrong — the classic: a row condition that would silently match zero rows forever — is named by a separate warnings layer at generation, validation, deploy and boot.

Why this works: the schema is a finite, validated vocabulary — a bounded decision space a cheap model edits reliably, instead of open-ended code it has to debug. That constraint shapes the whole engine: strict keys, multi-field 422s, errors written to be corrected by a model with minimal tokens.

In the binary

What ships when you deploy that one file

The API is the product, and the binary also carries its own tooling: interactive docs, a visual schema designer that deploys and migrates tenants, and an admin panel with per-tenant observability.

Appximo Studio — the visual schema editor showing a 10-resource e-commerce ERD
Appximo Studio at /editor — the schema as an ERD: entities, relations, RBAC, state machines; deploys with a migration preview.
Swagger UI at /docs showing the generated OpenAPI for a marketplace schema
/docs — the generated OpenAPI 3.0, interactive. Custom Go routes are listed too.
The admin panel showing tenants, served resources and data rows
/admin — tenants, users, data browser, observability (latency, SLO burn rate, traces).

Recent

What v0.1.10 → v0.1.13 changed (2026-08-27/28)

Six engine sessions in two days, each opened by a field report — one of them a real migration (Symfony 7.2, 23 tables, 46,119 rows, 1.2 GB of JSON) — and each closed against the released binary. Every line below was re-verified with a request against v0.1.13 before this page said it.

Known limits — said, not hidden

The full list with its trackers: GUIDE §9. The migration report that drove most of this, answered point by point — including the three points where the report's own diagnosis was wrong: FIELD_FEEDBACK_RESPONSE.md §5.

Numbers

Measured, dated, with their conditions

Every figure below was measured against a running engine and re-verified on 2026-08-01 (or carries its own date). The conditions are part of the claim — a number without its condition is marketing.

FigureValueCondition — read it
Sustained throughput2,000 req/s · p50 1.60 ms · 0 errors in 597,461 requests 2-vCPU $16 droplet, external loader over a real network; JWT + RBAC + multi-tenancy + validation active. Requires raising the per-tenant rate limiter (RATE_LIMIT_RPS=3000) — on the default 1,000 rps/tenant, ~half of a single-tenant 2,000 rps load is 429 by design.
Median latency, comfortable loadp50 1.53 ms @ 500 req/s Same stack; response cache on.With the cache fully bypassed — every request reaching PostgreSQL — p50 2.44 ms.
A million-row query~3 ms engine · ~4.2 ms over HTTPS Filtered + sorted + paginated page over 1,000,000 rows; does not degrade as the table grows (keyset pagination + real indexes).
Cost of the production layers≈ +1.2 ms p50 Caddy + real TLS in front of the engine, measured on both live demo apps (they agree to 0.01 ms).
Footprintengine ~21 MiB RSS idle · full stack ~186 MiB PSS under load Idle engine on a small dataset (2026-08-01); full stack = engine + PostgreSQL + Caddy serving the live shop at 200 req/s (2026-07-31).
Deploy blip~0.3–0.6 s of 502s Binary swap under live traffic (2026-07-31), health-polled, auto-rollback if the new binary fails (a deliberately broken deploy rolled itself back, unattended, in ~17 s). Honest sub-second blip — not zero-downtime.
Backup → restore drillrestore in 1.8 s Executed on the live shop (2026-07-31): schema dropped, restored, row counts identical, a new purchase completed. Rehearsed, not hoped.
AI schema generation~90 % first-try · 100 % convergence · ~$0.006/schema 120-case stratified NL→schema corpus, validator-guided loop, cheap model (Haiku), Wilson CIs / McNemar.
Field selection (?fields=)a page of 20: 961 KB / 53 ms → 3 KB / 1.2 ms · p99 @ 10 rps: 2.8 s → 175 ms A migrated system's list rebuilt: 46,119 rows × ~52 KB json documents (TOAST 1.8 GB), 1-vCPU dev box, 2026-08-28 — with vs without on the SAME binary (the projection reaches the SQL SELECT, so the document is never detoasted). Opt-in per request; the plain list is byte-identical. The deep-page cost that remains is the OFFSET (page 1000: 15 ms), not the document.

Sources and reproduction recipes: the certification report · BENCHMARKS.md (§4b for the ?fields= row). The repo ships the harness (scripts/bench-protocol.sh, scripts/verify-production/) so you can re-measure on your own hardware. No comparative claims against other frameworks are made here: the last such measurement (2026-06-10) predates today's conditions and was deliberately not re-run.

Fit

Who it is NOT for

The scale ceiling is a declared product range, not a bug. If any line below describes you, use something else — this list exists so you can decide in sixty seconds.

And who it is for

Live demos

Four production apps run on it today

Each with its own binary, database and Let's Encrypt certificate, on cheap VPSs. Two of them were built entirely by third parties working only from the printed contracts — the strongest evidence on this page. The largest, atina, is open: walk through it.

atina.appximo.com — kanban, livesilent loop · 9 s
atina — a multi-client recruiting SaaS built by an external developer with no contact with us: 32 schema resources, 48 custom Go routes and 30+ SPA screens in one binary, HTTPS. Numbers counted in its public /openapi.json. The build report, phase by phase →
atina — public portalsilent loop · 9 s
The public portal, the candidate area and the client back-office are one Svelte SPA served by the engine binary. Open atina.appximo.com → (the portal needs no account; the panels are the client's).
La Tiendita — the storefront on a phone viewport, with the customers/owner switch

tiendita.appximo.com

A commerce platform in framework mode: jsonb catalogue with GIN indexes, inventory that cannot oversell, order lifecycles, signed payment webhooks, storefront + back-office embedded in the binary.

Visit the shop →
Petfriendly — the demo landing: the owner's panel behind one click, the API docs behind another

petfriendly.appximo.com

A veterinary appointment API whose schema was AI-generated from one paragraph of Spanish — enforced lifecycles, per-vet row access — deployed through the same path as any hand-written schema.

Try the demo panel →
Crisblogs — a blog built end-to-end by a third party on Appximo

crisblogs — built by a third party

Built by a third party — an agent with no access to the engine's source, working only from the printed specs: a full blog with public reading, auth, and its own frontend served from the binary. 24/24 browser checks in a mobile viewport. Hosted on the author's own infrastructure.

Case study

VecinGo — an independent developer took a neighborhood-association platform (18 resources, 8 state machines, 13 custom Go handlers, weighted quorum voting, a 13-screen embedded SPA) to production with HTTPS in ~3–3.5 h, onto a VPS already serving two other apps. Verdict: "as a consumer, I would do it again." Including the four engine defects they found — and how each one was closed.

Read the case study →
the browser tour · v0.1.13 · 1:28 real time · subtitles ES + EN
What that one command leaves you in the browser, on the released v0.1.13: /app with its footer (page 1 of 8 · 15 of 112 · the engine's query time), a record's detail with its relations both ways, the JSON editor naming an invalid document before it is sent, columns and a saved view, CSV, a bulk transition of 15 rows through /api/transaction — then /docs, /editor and /admin. Real time, no speed-up (the top bar carries the clock). The schema is the demo's generated one plus one jsonb field added for the editor — how it was recorded, step by step. The previous tour is archived, not deleted.

Comparison

Where it sits — honestly

Different tools that overlap on “I need an API”. What each does better is stated, because you should pick the right one.

AppximoNestJS / RailsSupabasePocketBase
You writea JSON schema (+ optional Go)application codeSQL + RLS policies + client codecollections config + hooks
Multi-tenancyfirst-class: schema-per-tenant, physical isolationyou build ityou build it (RLS = logical)one DB per app
Databaseyour PostgreSQLanybundled Postgres (its platform)embedded SQLite
Runtimeone static Go binaryNode/Ruby + depsa service fleet (or their cloud)one Go binary
Custom logicGo in-process, same transaction + sandboxed JS/WASM hooksunlimited — it's your codeedge functions (another process)Go/JS hooks
Observabilityin-binary: metrics, traces, SLO, per-tenantyou assemble itrich in its cloudminimal

What they do better: frameworks give you unlimited logic with no ceremony. Supabase has a massive ecosystem — realtime channels, storage, hosted auth. PocketBase is simpler to run (no Postgres) and wins the simple single-tenant app on packaging. The Appximo lane: several physically isolated tenants on one cheap box, against a Postgres you control, with the API contract generated and enforced from a schema file — plus the 10 % as in-process Go in the same transaction. One structural example: per-tenant identity — the same email is a distinct account in two tenants, which a globally-unique-email auth model cannot express.

Trust

Don't believe this page — re-run it

The repo ships the instruments that produced every claim above: the benchmark protocol with statistical gates, a production-verification suite that runs against your server, an acceptance suite for the whole API surface, and a binary-diff gate with a 163-case behavioral corpus. The certification report documents what was verified, what was corrected, and what could not be re-verified — including the claims this project deliberately no longer makes.

Read the guide Read the certification What it does — and doesn't