Hosting an Osy# app

Zero to running — local dev#

osy init --agent claude
osy launch

That's it. osy launch compiles your project and opens it, starting the platform for you if one isn't already up — a real PostgreSQL (with pgvector), a real web server, and the entire runtime on your machine. No account. No cloud project. No connection string. Nothing to sign up for.

This is not a simulator or a mock. It's the same runtime with the same enforcement, which is why what works on your laptop is what works, full stop.

Make a change, compile, and it's on screen in seconds.

Your app is two things. You only write one of them.#

You write the source. Osyrin runs it.

Everything this documentation calls "built in" — the database, the web server, the client, the security model inside every query, durable workflows, the realtime channel — isn't something you wired up. It's already running. Your source is one half of the app. Osyrin is the other half, and it's the bigger one — what it promises while it runs is its own page.

Most teams spend the majority of their effort on that half. You spend it on the business.

What you get without writing any of it#

Your data. The schema comes from your model and follows it when the model changes. Constraints enforced on write. A function's writes land as one commit. Counters stay right under load. Destructive changes are refused until there's a migration you can actually read.

Who sees what. The security { } you declared is compiled into the query itself — a row filter and a field mask under every read your program can express. Not a check you remembered to add. Not a middleware someone forgot.

The screen. Routing, rendering, reactivity, a query that stays live and pushes updates, forms, the control kit, light and dark themes, and the hand-off to the server when a click needs one. Reconnects itself when the network drops.

Work that outlives the request. Workflow states, SLA clocks, reminders that fire on wall time. Effects that run exactly once — across a crash, across a deploy. Running instances keep executing their own version while you ship the next one.

The outside world. Typed HTTP clients. A REST API over your model. An MCP server for agents. Scheduled work. File storage.

Intelligence. LLM providers with streaming, tool calls and budgets. Embeddings and vector search from a [Searchable] attribute.

Seeing what happened. One correlation id from click to commit. Traces you can open. Faults captured whether or not you were looking.

Every line of that is a thing a team normally builds, operates, and keeps compatible with everything else. Here, it's simply there.

Deploying is not a binary swap#

Here's the thing that catches people: a compile doesn't produce a binary, a container, or a bundle. It produces your app's model and applies it to a platform that is already running.

So a deploy is a new version of a description landing on a live platform. No process gets replaced. Nothing gets drained. Workflows that were mid-flight keep going on the version they started under, and new runs pick up the one you just shipped.

You've never had a deploy that worked like that. It's what happens when the runtime owns the runtime.

Things you will never do#

• Size a server
• Pick a database tier
• Configure a connection pool
• Buy a domain, provision TLS, open a firewall port
• Stand up a load balancer
• Write a backup schedule, then rehearse the restore
• Tune autoscaling
• Add a migration runner to CI
• Push to a container registry

That list is the gap between "I have an app" and "other people can use it." On most stacks it's a week of decisions before the first person outside the room sees anything. Here it's the same command that's been running on your machine all along.

Once you're happy with it locally — self-hosted, and cloud#

The same source goes to a platform that isn't your laptop, with the verbs you have already been using — you point them at a server instead of letting one start itself:

osyrin login --server <url>                       # once
osyrin app create "Reelo" --server <url>          # once
osyrin app compile --server <url> --new-version   # every deploy, frozen as a version

--new-version is what makes a deploy safe while people are using the app: a run already in flight finishes on the code and data shape it started under, while new runs pick up what you just shipped.

Where it runs today#

Straight talk: this is early, and one hosting shape ships right now.

The path is already built into the command you use every day. osyrin app compile --server <url> doesn't care whether that platform is your laptop or a box in your own cloud — the model is the artifact, and the artifact doesn't know where it's being applied. Everything you build against the local platform carries over unchanged.

Try it#

Install the CLI, run osy init --agent claude, run osy launch. You'll have an app with a database, auth, and a live UI before you've finished your coffee — and you'll have written none of the parts that usually take the week.

See also#

• Osyrin, the runtime — Osyrin itself: what it promises while it runs, and what stands behind it
• Running a local platform — running a local platform
• Deploying while workflows are running — deploying while workflows are running
• Renaming and removing things that hold data — renaming and removing things that hold data
• How an Osy# app works (the execution model) — how an Osy# app works