Mistral Bought Koyeb: The Tenant Exit Playbook

On February 17, 2026, Mistral AI agreed to acquire Koyeb — its first acquisition ever — and fold the Paris serverless platform into Mistral Compute, its sovereign-European AI cloud. The price was undisclosed, and Koyeb's entire 13-person team, including three ex-Scaleway co-founders, joined Mistral engineering under CTO Timothee Lacroix.

New signups lost the free Starter tier overnight, and the roadmap tilted toward AI inference, GPU optimization, and enterprise on-premises deployments. If you run a standard web app on Koyeb, read that list again: none of those three things is you.

Seven months on, the platform still operates and existing accounts keep their tiers — Mistral promised a smooth transitional period, and so far it has kept that promise. But InfoWorld called the direction plainly: a strategic shift toward AI workloads, not general-purpose developer hosting. By August, tenants were already describing a dashboard visibly mid-transition. This post is the exit playbook for tenants reading this acquisition the way Heroku's sustaining-mode freeze taught the last generation: the verdict up front, then the primitive-by-primitive map of what ports cleanly and what was the lock-in all along.

The verdict: most of Koyeb ports in a weekend — Dockerfiles, the $PORT convention, domains, env vars, even Terraform state concepts all have direct equivalents. Three things do not: Light Sleep scale-to-zero, Serverless Postgres, and per-second serverless GPUs. Those three are the actual product you were buying, and they are the three rows of this playbook that deserve your planning time. Everything else is logistics.

The exit map: every Koyeb primitive, rated​

Here is the whole migration on one table, ordered roughly by how much of your weekend each row consumes. Each primitive gets a verdict — maps cleanly, needs work, or lock-in — plus the self-hosted equivalent I would reach for on infrastructure you own.

The rest of this post earns each row: first the portable half with its gotchas, then the three hard primitives with honest substitutes, then the move order and where to land.

What maps cleanly (and the gotcha in each row)​

Deploys. Koyeb builds from git or a Dockerfile, and a Dockerfile is the most portable artifact in this industry. It runs identically on Render, Fly, Coolify, Dokploy, Kamal, or a raw Kubernetes cluster.

The gotcha is everything around the Dockerfile: Koyeb's build caching behavior, its default work directory, and any entrypoint overrides you set in the dashboard rather than in code. Before you move, make every dashboard setting a file in the repo — entrypoint scripts, build context paths, health-check endpoints — or you will rediscover them at 2 a.m. behind a failing deploy on the new platform.

The $PORT convention. Koyeb, like Render and Heroku before it, injects a $PORT your service must listen on. Every Render-compatible self-hosted platform preserves this, so compliant apps move without code changes. The gotcha: hardcoded ports. Grep for 3000, 8080, and 8000 in listen calls now; each one is a small outage later.

Domains and TLS. Koyeb issues certificates for custom domains and hands every service a *.koyeb.app default. Automated ACME issuance is a solved problem on owned infrastructure — Caddy does it in one line, Traefik and cert-manager in a few more — and the migration virtue here is that DNS cutover is reversible. Point a low-TTL record at the new target, keep Koyeb warm behind you, and rollback is a DNS edit. The gotcha is certificate provisioning time on first issue plus validation records; pre-provision certs on the new platform days before cutover, not minutes.

Env vars and secrets. A flat key/value list copies across with a script. The gotcha is the secrets you forgot: third-party API keys scoped to Koyeb's egress IPs, OAuth redirect URIs pinned to *.koyeb.app or your old domain, webhook signing secrets validated against the old endpoint. Export the env list, then diff it against every external dashboard that references your app. One migration guide I found in the wild puts "remove the old redirect URI" as an explicit final step — that checklist exists because someone got paged.

Autoscaling and IaC. Min/max instance autoscaling maps directly onto HPA or KEDA replicas, and Koyeb's Terraform provider means your infra-as-code instincts transfer to OpenTofu plus Cluster API with the same declarative shape. The gotcha is that autoscaling on owned hardware scales replicas, not cost: the box is already paid for, so the policy question changes from "what will this cost" to "how densely can we bin-pack." That is a better problem, but it is a different dashboard.

What is genuinely hard (the actual lock-in)​

Light Sleep scale-to-zero. This is Koyeb's signature: idle services stop billing entirely and wake in about 200 ms. Kubernetes can technically do this — KEDA scalers, Knative serving, and in v1.37 even HPA scale-to-zero reaching beta — but the economics invert on hardware you own.

Scale-to-zero on a metered platform saves money because the meter stops. On a Hetzner box you already paid for, an idle-reaped pod saves nothing except headroom for neighbors. The honest substitute is bin-packing plus KEDA: pack preview environments and bursty services densely and reap them to zero for capacity.

What you give up is the true-zero bill for side projects. Price that loss explicitly: on Koyeb's metered tiers a service serving traffic two hours a day costs under a dollar a month in compute, while on owned hardware its share of the box is whatever fraction of always-on it occupies. For fleets of tiny services, that math can favor staying metered somewhere — which is exactly why the landing spectrum below has three options, not one.

Serverless Postgres. Koyeb's managed Postgres went GA in May 2025 with usage-based scaling, and the database is the line item that dominates small-app bills everywhere — a recent teardown priced managed Postgres at roughly 20x the cost of the Hetzner box underneath the same app.

Self-hosting Postgres on CloudNativePG is operationally mature but it is always on: no scale-to-zero, no branch-per-preview unless you build it, and you own backups, failover, and version upgrades. If your app genuinely needs serverless-database semantics, the substitute is Neon, not a self-hosted stack — accept one managed dependency deliberately rather than rediscovering the need mid-migration. What you give up self-hosting is elasticity; what you give up staying managed is roughly an order of magnitude in cost. There is no version of this row where you keep both.

Per-second serverless GPUs. Koyeb bills GPUs to the second — L40S around $1.55/hr, A100 around $2.00/hr, H100 around $3.30/hr at list, with cuts up to 24% announced in 2026 and a range stretching from RTX 4000 Ada cards to 8x H200s plus Tenstorrent accelerators in preview.

Nothing on owned hardware replicates per-second GPU billing, because the card is either in your rack or it is not. The workable shape is hybrid: owned GPU nodes for steady-state inference, burst vendors (RunPod, Modal, Lambda Labs) for spikes and experiments. What you give up is single-vendor simplicity and true scale-to-zero on accelerators.

And note the strategic irony: GPUs are the one Koyeb primitive Mistral is investing in — Koyeb's autoscaling and sandboxing tech now accelerates Mistral Compute inference, backed by 13,000-plus Nvidia GB300 chips and $1.4 billion in Swedish data centers. If GPUs are why you are on Koyeb, you may be on the side of the acquisition that gets better, not worse. GPU tenants should read the rest of this playbook as contingency, not urgency.

The exit sequence: data first, DNS last​

Heroku's sustaining-mode freeze taught a generation the order of operations, and it applies unchanged here: stateless services are a weekend; the data layer is the migration. Follow this sequence and each step stays reversible until the last one.

1. Export the data layer first. pg_dump every Koyeb Postgres database to versioned storage, restore into the new target, and verify the restore — row counts at minimum, application-level smoke tests if you can. Do this while Koyeb is still primary, when a bad dump costs you an afternoon instead of an outage.
2. Stand up staging against the real data shape. Deploy your services on the new platform pointed at a restored copy (not production). Reproduce entrypoints, env vars, and health checks from the repo files you created in the "deploys" step above. If OAuth redirect URIs or IP-allowlisted keys exist, stage those integrations now.
3. Move stateless services with Koyeb still serving. Dual-run: new platform live on a staging hostname, Koyeb on the production domain. Run an external uptime check against both. The Koyeb bill during overlap is your rollback insurance — budget two weeks of it and consider it cheap.
4. Cut over DNS with low TTL. Drop TTLs to minutes a day ahead, switch records, watch error rates on both sides. Keep Koyeb services scaled but undeleted for at least a week; rollback is one DNS edit.
5. Decommission deliberately. Only after clean dual-run plus a quiet week: delete Koyeb services, remove old OAuth redirect URIs and webhook endpoints, rotate any secret that ever lived in Koyeb env vars, and export final invoices for the books. Then cancel the plan — new accounts enter at $29/mo Pro with no free tier to fall back to, so a forgotten service bills at Pro rates, not hobby ones.

Where to land: the honest spectrum​

Three tenant shapes, three answers — pick by what your app actually is, not by loyalty to an abstraction.

Side projects and previews: stay metered, move platforms. If Light Sleep economics are why Koyeb worked for you, owned hardware will not reproduce them. Render is the closest workflow equivalent — git-push, $PORT, managed Postgres, flat per-service pricing without Koyeb's free-to-$29 cliff — and the alternatives guides uniformly name it first for standard web workloads. Your migration is the playbook above with a smaller step 5.

Production SaaS and APIs: self-host the fleet. Always-on services with steady traffic are where metered billing is pure margin for someone else. A git-push PaaS on machines you own — Dockerfile in, HTTPS out, Postgres on CloudNativePG, bandwidth at Hetzner's included-traffic generosity — collapses the ~$184/mo reference topology from the recent teardown toward single digits plus your ops time.

The honest cost is the ops time: you now own upgrades, failover drills, and the 3 a.m. page. Teams with one platform-minded engineer break even fast; teams with zero should stay managed until they hire one.

GPU inference: stay, hedge, or hybrid. As noted above, Mistral is investing in exactly this surface — serverless GPUs folded into a sovereign AI cloud with on-prem deployment options is a credible improving story, and Mistral's ~$400M ARR at 95% enterprise mix means the GPU roadmap has paying customers behind it. If you leave anyway, the hybrid shape (owned base capacity plus burst vendors) is the only one that reproduces both the floor and the ceiling of per-second billing. Do not self-host your only GPU and call it a migration; you have traded a meter for a single point of failure.

Whichever shape you are, the meta-lesson is the Heroku one: the platform was never the Dockerfile or the domain — those were always yours. The platform was the three rows marked lock-in, and the time to price their replacements is while the old dashboard still loads, not after the transition email lands.

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.