InferHaven's source code is live!

The source for inferhaven-core is live. As of today you can clone it, fork it, run it, audit it, learn from it, run it for your team at work, run it on the dusty homelab box next to your router. Everything you would expect from a project most people would call “open source” — except I’m not going to call it that, because it isn’t, quite. We released InferHaven under the Functional Source License (FSL-1.1-ALv2), which is a fair source license, and I want to spend a few paragraphs explaining why that’s a deliberate choice and not a hedge.

What fair source actually is

The shorthand: source-available, no rug pulls, time-bombed to a real open license.

Specifically, FSL-1.1-ALv2 gives you all the rights you’d expect — use it, modify it, fork it, ship it inside your product, run it for a thousand engineers — with one carve-out. You can’t take InferHaven and offer it as a competing hosted service that substitutes for what we offer. Two years after each release, that one restriction lifts and the code automatically becomes Apache 2.0. Forever. No revocation, no take-backs, written into the license itself.

That last part matters. The fear with any source-available license is that the company behind it goes hostile, changes the terms, or quietly disappears and leaves you holding code with murky rights. FSL has the conversion baked in — if InferHaven LLC vanishes tomorrow, the code from two years ago is already Apache, and everything after that converts on the same schedule whether we’re around or not.

Use it for almost anything. Don’t resell our work as a hosted product. In two years even that restriction is gone.

— The deal

Why not just MIT or Apache from day one

Honestly, I thought about it. The temptation to slap MIT on the repo and ride the warm fuzzy feeling is real. But I’ve watched this play out too many times to pretend I haven’t.

The pattern is depressingly consistent. A small team builds something good. They open-source it with a permissive license because that’s what you’re supposed to do. A hyperscaler — usually one of the same three — wraps it in a managed offering, slaps a logo on it, charges customers more than the original team ever could, and contributes nothing back. The original team eventually has to either commercialize aggressively, change their license (which always causes a community blowup), or quietly fade away while their work powers somebody else’s quarterly earnings call.

I’m not interested in that story. Not because I think hyperscalers are evil — they’re just doing what their incentive structure tells them to do — but because the only way InferHaven gets to be the thing I want it to be is if we get to grow at our own pace and own the hosted version of our own product. Fair source is the bargain I’m willing to make to keep that path open.

What this means for you, concretely

If you’re a developer who wants to run InferHaven on your laptop, your homelab, your team’s GPU box, your company’s bare-metal cluster — nothing changes. Clone the repo, run docker compose up -d, you’re done. Same as if it were MIT.

If you’re a company that wants to run InferHaven for your internal engineering team — even a very large engineering team — go for it. That’s “internal use and access,” which is explicitly a permitted purpose under the license.

If you want to fork it, modify it for your specific workflow, contribute back upstream, package it for a Linux distro, build educational content around it, write a book about it, use it as a teaching tool, integrate it into your homelab YouTube channel — all of that is fine.

The single line you can’t cross is wrapping the code into a hosted, managed service that competes with what we’re building. That’s it. If you’re not a cloud reseller, the license is functionally invisible to you.

What “haven” actually means to us

I want to be clear about something, because I think it sets the tone for everything else: InferHaven is named what it’s named on purpose.

A haven is a harbor. A place ships pull into when the weather turns or when they just need somewhere safe to sit for a while. It’s not a paywalled fortress, it’s not a destination resort, it’s a working port that does its job and lets you keep moving when you’re ready. That’s the vibe I want for the company.

Which means a few things, in practice, that I’m putting in writing here so you can hold me to them.

We are not going to maximize profit per user. We are going to charge enough to keep the lights on, pay the people building this thing a fair wage, and reinvest in making it better. That’s it. If we ever find ourselves on a call talking about “expanding ARPU” or “monetizing the long tail of the install base,” somebody on the team has permission to throw a stapler.

We are not going to dark-pattern you into staying. If you self-host and you want to migrate off to something else, we might even be able to help. If you’re on the cloud and you want to take your models and your config back to your own hardware, the same docker compose up -d flow works. The exit door is the same size as the front door and it’s never locked.

We are not going to ship features whose only purpose is to make the next quarter look better. Telemetry stays off. The marketing site has zero trackers — go look at the network tab. The product is the product, the pricing is the pricing, we’ll tell you what we’re doing and why.

A haven for your inference workloads. Pull in, do your work, leave when you want, come back when you need to. The lighthouse will stay on.

— InferHaven, the working definition

The road to InferHaven Cloud

The other reason today matters: shipping the source is the prerequisite for the next thing we’re building, which is InferHaven Cloud.

The pitch is straightforward. Same Docker stack you can run on your own hardware, except we run it for you on real GPUs in real data centers, and you get a control plane on top that handles provisioning, model management, SSH key rotation, billing, multi-server fleets, and the rest of the boring infrastructure stuff that most people don’t actually want to manage. You point a dashboard at it, you push a button, you have a workspace.

The honest status: it’s well underway. The provisioner works, the agent protocol is locked, the dashboard is rendering, the relay is running, the billing integration is mostly wired up. There is a real long list of things between “mostly works” and “I’m willing to take your credit card for it,” but the shape is there and we’re grinding on it daily.

$ haven cloud servers list
NAME              STATUS    REGION   GPU            MODELS
codex-prod        RUNNING   nbg1     RTX-4090       qwen2.5-coder:14b, llama3.3:70b
codex-staging     RUNNING   fsn1     RTX-3090       qwen2.5-coder:7b
homelab-mirror    OFFLINE   self     RTX-A6000      (last seen 3h ago)

The target window is 2-3 months from today for a public beta. I’m being deliberately squishy on the exact date because the only thing more annoying than software that ships late is a founder who keeps promising it’ll ship next Friday. When it’s ready, it’s ready, and you’ll know because there will be a button on the homepage that wasn’t there before.

If you want to be in the first wave, the waitlist on the homepage is the way in. We’re going to bring people on slowly because I’d rather have a hundred happy users than ten thousand frustrated ones in week one.

How to actually get involved today

The thing I’d most love right now is people running the self-hosted stack and telling me what breaks. The repo has issue templates, the CONTRIBUTING.md walks through the dev loop, and I read every issue that comes in.

$ git clone https://github.com/InferHaven/inferhaven-core
$ cd inferhaven-core
$ cp .env.example .env
$ docker compose up -d
$ open https://localhost && ssh haven@localhost

If you’re the kind of person who likes reading code more than reading marketing pages — fair, same here. In the repo, the deep-dives are under docs/, and the whole thing is intentionally legible. No clever metaprogramming, no architecture astronaut diagrams, no eighteen layers of abstraction wrapping a single docker exec. It’s bash and compose and a Caddyfile and a couple of small Node services, organized so you can pick up any one piece and have a fighting chance of understanding what it does.

Where this leaves us

Today the source goes public. The next few months are heads-down on cloud. The license is the license, the conversion clock is ticking, and somewhere two years from now the first commits drop into Apache like a message in a bottle washing up on shore.

Float your boat up to the dock, clone the repo, tell me what’s broken, and stick around for the cloud beta. The lighthouse is on.

— Ethan L.