Own your backendin one click.

What you just watched

The teaser runs the full Wyro loop in about twenty seconds: you compose a backend on a canvas, press Compile, and read the TypeScript that comes out. Nothing in it is a mock-up of a feature that doesn't exist — the canvas, the compile step, and the source export are the product. Here is the same story in text.

1. Design. Drag blocks — API routes, Postgres tables, auth, queues, scheduled jobs, integrations — onto an infinite canvas and wire them together. The edges you draw become real queries and real call graphs, not annotations.
2. Compile. One click turns the graph into a typed codebase. The compiler walks your canvas into an intermediate representation and emits ordinary files from it, so two compiles of the same graph produce the same repository.
3. Own it. Export the repo as a ZIP or push it to Git. It carries a Dockerfile, a compose file, and a README, and its dependency tree is the one you'd expect — Express, Drizzle, Zod — so npm install && npm test is the whole setup and every file is one your team can read on its own terms.

What the compiler emits

An exported project is a conventional Express application. There is no framework of ours in the dependency tree and no runtime that phones home — the layout below is what lands on your disk:

src/
  index.ts              Express app, middleware, route mounting
  api/*.ts              one handler module per route block
  db/schema.ts          Drizzle table definitions
  db/schemas.ts         Zod validators derived from the schema
  db/index.ts           pooled Postgres client
  db/rls-policies.sql   row-level security, when the canvas asks for it
  middleware/auth.ts    JWT verification
  auth/oauth.ts         provider sign-in flows
  auth/rbac.ts          role checks
  jobs/*.ts             queue consumers and cron handlers
  flows/*.ts            multi-step flows composed on the canvas
  logic/*.ts            branch, map, filter and transform steps
  integrations/*.ts     third-party service calls
  __tests__/smoke.test.ts
Dockerfile              docker-compose.yml   railway.json
package.json            tsconfig.json        drizzle.config.ts
.env.example            .gitignore           README.md   LICENSE

The runtime dependencies are the ones you would have picked yourself: express, drizzle-orm, postgres, zod, cors, helmet, morgan, jsonwebtoken and nodemailer. Every one is a package you can look up, audit, and replace.

The same check, on code Wyro never wrote

Generating a backend is the easy half. The compiler emits typed handlers with authentication on every route, indexed foreign keys, and money as integer cents — but the interesting question is whether the code you already have does the same. So the engine runs both directions: point it at a GitHub repository, a commit in CI, a ZIP exported from v0, Lovable or Bolt, and it rebuilds the architecture from the source and checks it.

It reads Express, Next.js App Router, NestJS and FastAPI, across Prisma, Drizzle, SQLAlchemy, Mongoose and TypeORM, and it looks for one thing above all: a route that reaches your data without checking who is asking. When it cannot read a repository it says so, and says what the repository looks like instead — because an empty result reported as a clean one is worse than no answer at all.

Where it runs

Anywhere Node runs. The export ships a Dockerfile and a compose file for local work or any container host, and a railway.json for one-command Railway deploys. Vercel, Fly, Render, a VM, or your own hardware all work the same way, because what you are deploying is a plain Node service. Bring your own Postgres, or let Wyro provision a managed one — the databases guide covers both.