You don't own your work OS. That's the problem.

Think about where your company’s actual operating data lives. The client list. The project history. The pipeline. The content calendar with two years of context in it. For most teams, all of it sits inside SaaS tools you don’t own, can’t inspect, and can’t run yourself. You’re a tenant. And tenants get evicted.

This isn’t hypothetical grievance. It’s the recurring pattern of the last decade of work software, and it plays out three ways.

The three ways closed tools fail you

Pricing that moves after you’re committed. The tool is cheap and generous while it’s acquiring you. Then the per-seat price goes up, the useful features migrate to a higher tier, and the automation limits tighten. You don’t leave, because leaving means re-modeling your entire business somewhere else. That switching cost is the product. The lock-in was always the plan.

Your operations are structured data. The question is whether you own the structure.

Your data in a shape you can’t take with you. Sure, there’s an “export” button. It gives you a CSV of rows and strips exactly the thing that made your setup valuable — the relationships. The link between a project and its client, a task and its deliverable, an invoice and its account. Export the tables and you get a pile of disconnected spreadsheets, not your business. Real portability means taking the model, not just the cells.

The tool decides, and you live with it. A feature you depend on gets deprecated. A limit you never hit before starts blocking you. An integration you rely on gets pulled behind an enterprise plan. You had no vote and no visibility, because it’s someone else’s code on someone else’s servers, and you can’t see what it does or change what it doesn’t.

None of this requires a villain. It’s the ordinary physics of closed, rented software: the incentives point at retention and margin, and your ownership is the thing that gets traded away.

What “you own it” actually requires

“Own your data” is a slogan every vendor uses, usually while your data sits on their servers under their terms. We think ownership is concrete, and it takes three things that closed SaaS structurally cannot give you:

The whole workspace — records, files, schema — lives in your Postgres when you self-host.

1. You can read the source. Not a trust-us security page — the actual code. What it stores, what it sends, how it validates. StoryOS is AGPL-3.0. The whole thing is public and auditable.
2. You can run it yourself. Not “request a self-hosted quote.” One Docker command brings up the full stack on your own box. Your records, files, and documents live in your Postgres. No third party is in the path.
3. You can leave with the model intact. Because the schema is yours and the database is standard, your relations come with you. There’s no proprietary format holding the structure hostage.

When all three are true, the vendor relationship inverts. We can’t quietly raise your price on data we don’t hold. We can’t deprecate a feature out from under a copy you’re running yourself. We can’t lock you in, because the exit is always open. The only way we keep you is by staying good enough that you choose to stay. That’s the relationship we want — and open source is the only thing that actually enforces it.

Why AGPL, specifically

We didn’t pick the most permissive license. We picked AGPL-3.0 on purpose. It says: use it, fork it, run it, build a business on it — and if you offer a modified version to others over a network, share those modifications back. That keeps the project honest in both directions. You can’t be locked out of StoryOS, and StoryOS can’t be quietly captured, closed up, and turned into the exact thing we’re reacting against. The commons stays a commons.

For most teams the practical read is simpler: self-hosting is free and complete. Every view, every formula, every automation, the whole MCP server — no feature caps, no telemetry, no “contact sales.” The full product runs on your hardware because the full product is the open-source project.

”But I don’t want to run servers”

Fair. Most people don’t, and self-hosting isn’t the point — optionality is. The point is that hosting is a convenience you can buy, not a hostage situation you’re trapped in.

So we’ll offer managed cloud for teams who’d rather we handle backups, updates, and a hosted MCP endpoint. Same product, none of the ops. The difference from ordinary SaaS is what’s underneath: if our pricing ever stops making sense, or you decide the data should live on your own infrastructure, you take the open-source version and go. Nothing to re-model. Nothing left behind. The cloud is a service we earn every month, not a wall we build around you.

That’s the whole idea. Your business should run on software you can see, run, and leave. Anything less and you don’t own your work OS — you’re just renting it until the terms change.

Self-host StoryOS → · Read the source →