Deprecating the Dev Server API

Freestyle has decided to deprecate our Dev Server API. To any existing users who have not yet transitioned to our new VMs solution, contact us at founders@freestyle.sh.

What is being deprecated?

The Dev Server API including anything in our API docs under /ephemeral/v1/dev-servers/ is being deprecated. This includes all endpoints related to creating, managing, and interacting with Dev Servers.

What should you move to?

The successor to the Freestyle Dev Server API is the Freestyle VMs API.

Why are we deprecating the Dev Server API?

We started on the Dev Server API around March 2025 based on our conversations with AI App Builders on our platform. They were struggling with consistent start times, versioning, caching and cost for their users' environments.

To solve these problems they built complex orchestration engines around caching, warming, etc.

We believed we saw the answer: All of these VMs boiled down to a git repository and 3 commands: npm install, npm run dev, and curl localhost:3000 (to health check/preheat).

The Dev Server API was built around this concept: Users bring a repo of code and those commands, we handle caching, fast start times and version syncing.

Key Features

Fast Startup Times: Our Dev Server API needs to get initial responses quickly
Healing: When NextJS crashes we want to be able to restart it without the user having to do anything
Version Syncing: When users push new code to their repo we want to be able to sync it to their Dev Server without them having to do anything
Persistent URLs: Each Dev Server has a URL that is the same over time, no broken URLs after the user leaves the tab open over night
Debuggable: Debugging other solutions was extremely hard, we wanted to make solving problems in the Dev Server API easy
Cost Effective: We wanted to be able to offer the Dev Server API at a price point that made sense for AI App Builders and their users, which meant we had to be careful about how we used resources.

Initial Launch

We finished a P0 of it around May 2025 and tried onboarding users immediately — it was too slow. We had built our initial POC on top of Google Cloud Kubernetes, and the pods took too long to start. Even after building out preheated pools we couldnt crack 2-4 second initial response times.

Version 2: Not to be

After losing a user to a competitor with a VM solution, we decided to build out our own. This took us until September 2025 to get something that was properly good — we could then see the initial response times in hundreds of milliseconds we had been looking for with the Dev Server API.

However, when we went to onboard users onto the Dev Server API in September and November we noticed that the role of an AI App Builder had changed. It was no longer just 3 commands, app builders had moved on to include databases, multiple services and more complex architectures. We tried to hack things into working with the dev server API with tricks like post-install hooks and pre-start hooks, but it became clear P0 of the Dev Server API was not powerful enough for the current (or next) generation of AI App Builders.

When we started designing Dev Servers V2 we focused on multi-step and multi-service self healing architectures. We wanted users to be able to spin up a postgres database, redis, and a nextjs dev server, cache it, then base their user environments on it. Then, if any of them crashed and needed to be restarted we wanted to be able to do it smoothly. When we looked into building this, we realized Linux already had via Systemd. Because of this, we built a systemd API into our VMs that the Dev Server V2 API used to orchestrate any services users wanted in their environments.

We strongly believe Dev Environments should be ephemeral. All things should be ephemeral when possible, and because source of truth for the code lives outside of the Dev Environment there is no reason to force it to be stateful. With VMs, we solved this by inventing the concept of sticky VMs — VMs that aren't deleted after each use, but aren't guaranteed to be stored forever. This means we can offer cheap, fast storage and start times while not billing users for storage they aren't using. Then, because we use declarative configs for systemd, we invented the concept of recreate VMs — VMs that can be reconstructed after they've been deleted based on their config. Using this we were able to make Dev Servers V2 have caches to make it more consistently fast.

After we built this out, we realized the Dev Server API was a less powerful wrapper around the VMs API. There are a few things it made nicer, but more than anything it became a database table that mapped Git Repos to VMs — not a whole product.

Because of this, we went all in on the VMs API, and are now confident in saying that any use case the Dev Server could handle, the VMs API can handle better.

Design Mistakes

We made a few key design mistakes in the Dev Server API to do with ambiguity.

Ambiguous Git Keying: We lacked a clear strategy for uniquely identifying which git state a Dev Server should track. When users reference dev servers they referenced by repo and commit. However, this didn't account for what happens after the pull. This ambiguity led to confusion about which version of code a Dev Server was bound to. Without explicit keying semantics, it was unclear whether a Dev Server was tied to a specific commit, branch tip, or tag, making it difficult to reason about what code was actually running.
Ambiguous Caching: It was not clear to the user what was cached and what wasn't. This was a problem when it came to stale caches.

Design Wins

Durable URLs: The Durable URLs of the dev servers were a hit. Users loved that they could store them once and they would always work.
MCP: The Dev Server MCP was a super simple way to connect AIs to dev environments. It made for extremely simple onboarding and POCs.

The Future

We encourage all users to transition to the VMs API as soon as possible, and are here to help with any questions or support needed during the transition.

When we built the Dev Server API we underestimated how much smarter AI would get and how much more they'd be capable of — so we built the most basic solution possible to fit the time. This time, we overshot. Freestyle VMs are the most powerful solution on the market with support for nested virtualization, multiple services, multiple Linux users and much more. This is the future of dev environments, and we're excited to see what you build with it.

We'll be officially removing the Dev Server API from our APIs on March 1st, 2026.