Dora NodaFourteen people built the largest developer network in the open-model ecosystem, and on July 9, 2026 investors priced it at enough to make "run the model on your own infrastructure" look like the safe bet, not the scrappy one. Ollama closed a $65 million Series B, and the number that matters more than the check size is what it's chasing: 8.9 million monthly active developers, a number that's roughly doubled since January, and adoption inside 85% of the Fortune 500 — including regulated industries that don't let sensitive data anywhere near a third-party model API.
For a self-hosted PaaS deciding what ships as the default way a tenant runs a model, that's not background noise. It's a data point about which side of the "proxy to a hosted model API" versus "run the model on infrastructure you already control" question the market already answered.
The Numbers, Up Front
The round was led by Theory Ventures, with Benchmark, 8VC, Y Combinator, Pace Capital, 49 Palms, and GTMFund participating, bringing Ollama's total funding to $88 million since it launched in 2023. The traction underneath it:
- 8.9 million monthly active developers — roughly 2x since January 2026, the fastest stretch of growth in the company's history
- 67,000+ community-built integrations — the ecosystem surface that makes "just point your existing tool at Ollama" true in practice, not just in theory
- 85% of the Fortune 500 running it, including healthcare, finance, and government — the sectors most allergic to sending prompts to a vendor's API
- Partnerships with every major model lab and hardware vendor, so day-one support for new open-weight releases isn't a maintenance burden Ollama's own 14-person team has to carry alone
The company is also using the round to launch Ollama Cloud, a hosted tier billed on GPU time, not tokens — Free, Pro ($20/mo), and Max tiers, metered by actual infrastructure utilization instead of a per-token meter that penalizes long context. That pricing shape is worth remembering, because it's about to matter twice in this post: once as a precedent, and once as the tension in the honest tradeoff below.
The 85% Fortune 500 figure is the number that should actually move a self-hosted PaaS's roadmap, because it's not evenly distributed across use cases — it's concentrated in exactly the sectors where "just call a hosted model API" was never a real option. A hospital system can't send patient records through a third-party inference endpoint without a business-associate agreement most model vendors won't sign at any price; a bank's compliance team doesn't want prompt logs sitting on infrastructure it doesn't control; a government agency has procurement rules that rule out most SaaS AI vendors outright. Those buyers didn't adopt Ollama because it's trendy — they adopted it because "the model runs on hardware we already audited" was the only answer their compliance posture allowed. A self-hosted PaaS selling to that same buyer inherits the identical constraint, which makes local model serving less of a nice-to-have feature and more of a prerequisite for even being considered.
What Ollama Actually Is Under the Hood
Strip away the funding headline and Ollama is one binary that does three unglamorous jobs well: it pulls a model (from its own registry or any GGUF file on Hugging Face), quantizes it to fit the hardware in front of it, and serves it over a stable HTTP API — including an OpenAI-compatible endpoint at /v1 that lets any tool built against OpenAI's SDK point at localhost:11434 with a one-line base-URL change and keep working.
That's the whole pitch, and it's a boring one on purpose. A self-hosted PaaS doesn't have to build model pulling, quantization, or an OpenAI-shaped serving contract from scratch — it's already a solved, funded, actively-maintained open-source problem with 67,000 integrations that already assume it's there. Bundling Ollama as a tenant-facing primitive means an app on the platform can request local inference the same way it requests a Postgres add-on: declare it, get an endpoint, done. No tenant traffic has to leave the fleet to reach a model.
Ollama vs. vLLM: Where the Line Actually Sits
This blog already covered what it takes to run vLLM as a tenant model server on Cluster API-managed GPU nodes — the scheduling and routing mechanics of production-grade serving. Ollama isn't a competitor to that setup; it's a different point on the same spectrum, and the gap between them is measurable, not just architectural.
Ollama's OLLAMA_NUM_PARALLEL defaults to 4 concurrent requests per model, with anything beyond that queued (OLLAMA_MAX_QUEUE, default 512) rather than truly parallelized — because underneath the friendly CLI, it's still llama.cpp doing batch-level, not token-level, scheduling. vLLM's continuous batching admits new requests into an in-flight batch token-by-token instead of waiting for a batch window to close. The published gap is not subtle: one Red Hat benchmark on an A100 clocked vLLM at roughly 793 output tokens/sec against Ollama's ~41 tokens/sec at 128 concurrent requests, with vLLM's throughput climbing from 2.61 to 15.20 requests/sec between 10 and 100 simulated users while Ollama's plateaus near 0.45 requests/sec and its average latency stretches from ~21 seconds to over 100 seconds under the same load.
That gives a decision rule, not just a vibe: a single tenant hitting a model for its own dev/prototyping traffic, or a handful of low-concurrency internal tools, stays well inside Ollama's default parallelism and never notices the ceiling. The moment a platform is serving one model to many concurrent tenant requests — a production inference endpoint, not a personal dev loop — the queue depth and latency curve above are exactly the failure mode vLLM's routing and batching exist to solve. The primitive a PaaS bundles should match which side of that line the workload sits on, and there's no reason it has to be only one or the other.
What Bundling Ollama Actually Looks Like on bex
Concretely, this means a tenant's bex.yml gets a model block instead of an environment variable pointing at someone else's API key:
services:
api:
build: .
model:
runtime: ollama
pull: llama3.1:8b
gpu: gex44On the control-plane side, that resolves to the same shape every other bex primitive already uses: a MachineDeployment on a GPU-labeled Cluster API Provider Hetzner node pool, an ollama pull executed as part of the model container's startup, and an internal OpenAI-compatible endpoint (http://model.internal:11434/v1) the tenant's own services call — no outbound traffic to a hosted model API, no per-token bill arriving from a third party, no prompt data leaving hardware the tenant already trusts. For a team currently proxying every inference call out to a hosted API, that's the same self-hosting argument this blog has made about Postgres, object storage, and now the model layer itself: own the primitive that's already on your machines instead of renting it back over the network.
The Honest Tradeoff
Here's the part worth saying plainly instead of glossing over: the same $65 million round that proves "run the model yourself" won a fourteen-person open-source company real enterprise trust is also funding Ollama Cloud — a hosted, GPU-time-billed inference product aimed at exactly the buyer a self-hosted PaaS is trying to keep. Ollama's own roadmap now has a commercial incentive pulling toward "let us run it for you," the identical pitch a self-hosted platform exists to be the alternative to.
That's not a reason to skip bundling Ollama — it's a reason to be precise about what gets bundled. The durable layer isn't the Ollama company or its cloud product; it's the open format underneath it. GGUF is a portable model format, llama.cpp is the open-source inference engine Ollama wraps, and both work identically whether Ollama's binary is doing the wrapping or a platform swaps in a different one later. Bundling Ollama's binary and API shape as the default is the right call for the ease-of-use case it wins today — the risk is treating that binary as load-bearing infrastructure rather than the friendly interface on top of a format a platform never has to depend on any single vendor to keep serving.
The practical hedge is cheap: keep the tenant-facing contract at the OpenAI-compatible /v1 API surface, not at Ollama's CLI or registry format specifically. Any inference runtime that speaks that same API — llama.cpp's own llama-server, vLLM, or whatever ships next — can sit behind the identical endpoint without a tenant's app code changing a line. That's the same portability argument this blog has already made about Render-compatible APIs one layer up the stack: the value is in committing to the interface, not to whichever vendor happens to implement it best this year.
What This Actually Changes
Ollama's Series B doesn't tell a self-hosted PaaS anything it didn't already believe about running infrastructure on owned hardware — it tells it that 8.9 million developers and 85% of the Fortune 500 now believe it too, which is a different kind of validation than a roadmap conviction. The concrete move isn't "wait for Ollama to ship a Kubernetes-native serving story" — it's bundling the binary that already exists as the low-concurrency default, keeping vLLM as the answer once tenant traffic actually needs continuous batching, and treating GGUF as the portable contract that makes neither dependency permanent.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources
- Ollama Raises $65M in Series B Funding
- Popular open source AI developer tool Ollama raises $65M, grows to nearly 9M users — TechCrunch
- Ollama Raises $65M Series B Funding to Grow Its Open Source AI Platform — AIwire
- Ollama Cloud Pricing: GPU-Time Billing for Hosted Models
- OpenAI compatibility — Ollama docs
- How Ollama Handles Parallel Requests
- vLLM vs Ollama: Which LLM Serving Engine Handles Real Concurrency in 2026?.
