# Hosting an Osy# app

> You never set up a database. You never started a web server. That wasn't a step we skipped — it's the product.
> 
> Your app is two things and you only write one of them: you write the source, Osyrin runs it. Today it is hosted one way, on your own machine; self-hosting is next.

<!-- id: project-hosting · area: project · stability: stable · html: https://osysharp.com/reference/project/hosting/ -->

## Zero to running — local dev   {#zero-to-running}

```console
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.   {#summary}

You write the source. [Osyrin](https://osysharp.com/reference/project/runtime/) 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](https://osysharp.com/reference/project/runtime/) 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   {#description}

**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   {#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   {#never}

- 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   {#deploying}

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:

```console
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.

### The free tier, and what happens to an app nobody uses   {#free-tier}

A free hosted app is meant to be run, not just parked: it comes with enough execution time to serve a small app for
real, and more usage is what the paid tiers buy — more of that time, not a different platform. A free hosted app
runs for as long as someone uses it. An app that nobody has visited, deployed to or signed in to
for ninety days is marked dormant and its owner is told; any visit, deploy or sign-in resets the clock. Thirty days
after that notice, still untouched, the app and its data are removed — after a final backup, which stays
downloadable for thirty more days. Paid apps are never removed for inactivity, and none of this applies to the
local runtime or to a server you run yourself, which are your machines. The exact numbers are the tier's terms and
may be shortened with thirty days' notice on this page.

## Where it runs today   {#today}

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

| | |
|---|---|
| **Developer hosting** | **Available now.** `osyrin dev` on your own machine. Real runtime, real database, one command. Everything in this reference runs on it. |
| **Self-hosting** | **Next.** Run Osyrin on infrastructure you control. |

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   {#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   {#see-also}
- [Osyrin, the runtime](https://osysharp.com/reference/project/runtime/) — Osyrin itself: what it promises while it runs, and what stands behind it
- [Running a local platform](https://osysharp.com/reference/local/running-a-local-platform/) — running a local platform
- [Deploying while workflows are running](https://osysharp.com/reference/project/app-versions/) — deploying while workflows are running
- [Renaming and removing things that hold data](https://osysharp.com/reference/project/renaming-and-removing/) — renaming and removing things that hold data
- [How an Osy# app works (the execution model)](https://osysharp.com/reference/project/index/) — how an Osy# app works