Define data, policies, server functions, and live clients in TypeScript. Run it anywhere, or deploy it on Stack0 Cloud.
Add --template saas to start from one of 18 working apps.
Typed schema
entities, migrations, types
You write one schema. The same server stores the data, checks permissions, pushes updates, runs your code, and renders the pages. You do not add a second service for any of it.
Write each entity and field one time. Pylon makes the tables, runs the migrations, and writes the client types.
Subscribe one time. After each write that affects the result, the server sends only the rows that changed. You do not poll or clear a cache.
db.useQuery("Order")liveEvery read and every write goes through the same rules. An operation with no rule is denied.
Use email links, OAuth, OIDC, or API keys. Your functions and your access rules read the same session.
The app signs the upload. Files go to local disk in development and to any S3-compatible bucket in production.
Send cursors, typing signals, and who is online over a separate channel. None of it is written to your tables.
Run full-text queries with ranked results and facet counts. The index updates in the same transaction as the write.
Start on a single SQLite file. To move to Postgres, point DATABASE_URL at it. Your schema, rules, and client code do not change.
Pages are files. The server reads your data, streams the HTML, then hands the page to the client, which subscribes for updates.
Write a query, a mutation, or an action. Pylon checks the inputs and gives the client a typed function to call it.
The server records which rows a join or a total read. It runs the query again only when one of those rows changes.
Queue email, file processing, and totals to run after you reply to the user. Schedule work once or on a repeat.
Each step is saved as it finishes. A job can wait days for an event, then continue after a deploy or a crash. Finished steps do not run twice.
Open Studio to read the tables, watch live queries, follow the logs, and run a mutation against the environment you are debugging.
Choose a complete app. Run one command, read the source, and change what you need.
A complete SaaS product with a marketing site, onboarding, a multi-tenant dashboard, and Stripe billing. Reach for this one to build a product.
Rules, commands, types, data, and logs stay in one workflow. Your agent can create, run, inspect, and deploy the app without changing tools.
New apps include AGENTS.md and the Pylon skill. The agent reads project rules before it edits code.
Read the skillAGENTS.md.agents/skills/pylon/SKILL.mdapp.tsRun npm create, pylon dev, and pylon deploy from one terminal.
See cloud deploymentnpm create @pylonsync/pylonpylon devpylon deployGenerated clients turn schema drift, missing fields, and invalid arguments into compile errors.
See server functionsdb.useQuery("Order")Property "owner" does not existBuild stopped before deployThe agent can inspect tables, live queries, and logs in /studio while the local server runs.
See Studio/studio/tables/studio/live-queries/studio/logsDeclare an entity and its access policy. Pylon creates the table, REST and realtime API, row-level checks, and typed React client. That keeps resolvers, an ORM layer, and a separate backend service out of your stack.
// one entity → a synced table + typed clientconst Order = entity("Order", { customer: field.string(), total: field.float(), paid: field.boolean().default(false),}); // access rules next to the schema. Deny by default.policy({ entity: "Order", allowRead: "auth.userId != null", allowInsert: "auth.userId == data.ownerId",}); // the React side: live, typed, no fetchconst { data } = db.useQuery("Order");A repository push and a CLI release use the same build, preview, and production path.
Install the GitHub App once, or use the CLI from CI.
Each pull request gets an isolated preview environment.
Pylon validates the app and applies the schema before cutover.
The release moves to production with the same runtime.
One release path
Preview environments disappear after merge. Production keeps the release history and logs.
Every app sits behind a global edge network. Resize machines, add replicas and regions, or expand storage from the same dashboard, without pre-provisioning or per-seat pricing.
Cloudflare's edge provides CDN caching, TLS, and DDoS protection worldwide with no extra configuration.
Add RAM up to 64 GB, choose performance CPUs, and expand the volume without redeploying.
Run up to 32 load-balanced replicas per region.
Deploy in US, EU, APAC, and South America regions.
Grow storage live when the app needs room.
Bundled SQLite by default; co-located managed Postgres is in private beta.
Scale to zero when idle, or keep a project always warm.
Bring your domain; Pylon handles TLS.
Configure org-level SSO from the dashboard.
Activity log, one-click volume restore.
Everything else is in the docs.
SQLite is the default. It uses one file and needs no setup. Set DATABASE_URL to a Postgres connection string to use the same schema and application code with Postgres. On Cloud, bundled SQLite is the default. Co-located managed Postgres is in private beta.
No. The runtime is one open-source binary. Run it on your own computer or container platform with a volume for SQLite, or use your own Postgres database. Cloud is the managed option, not a requirement. It runs the same binary.
Your schema is TypeScript. In development Pylon diffs it and applies the change on save, so the tables follow the file. On deploy the schema is applied as part of the release, before traffic cuts over.
Two ways into the same runtime. Install the GitHub App and pushes to your default branch deploy, with pull requests getting preview environments. Or run pylon deploy from your machine or CI when you want a manual release.
A typed React client with server-side rendering, and a Swift SDK for mobile. Every entity also gets a REST and realtime API, so anything that can speak HTTP or WebSocket can read and write subject to the same policies.
Magic-link email, 25+ OAuth providers, generic OIDC discovery, guest sessions, and API keys. Whatever the caller signed in with, policies read the same auth.userId, so access rules do not change per provider.
Yes. ctx.scheduler.runAfter, runAt, and cancel schedule follow-up work. Delays and retries run in the same process as the rest of your app. You do not deploy a separate queue or worker.
It is a SQLite file or an ordinary Postgres database, with no proprietary storage layer in between. Take a dump and it opens in any client. What you would rewrite on the way out is the SDK calls, not the data.
Self-host the framework, or use Stack0 Cloud to run it. Connect GitHub or deploy from the CLI.