Enterprise-ready reliability: Why Ferndesk moved its AI help center to Render

Founded

2025

Industry

AI, SaaS

Migrated from

Railway

Image of Ferndesk home page that describes their ai-native help center as the The help center for those who hate writing docs

Ferndesk runs an AI-native help center that updates itself. Its agent, Fern, connects to a customer's codebase, product, and support conversations, and then automatically drafts and publishes help center content. When larger enterprises began to depend on Ferndesk, and the reliability of their PaaS provider started to waver, they moved to Render.

Wilson Wilson started Ferndesk after living the problem at his previous company: a small support team, a rapidly growing product, and documentation that fell further behind with every release. With AI, he saw an opportunity to build a better, more intelligent help center, and he built it the way he likes to work: lean and agent-first.

Initially, infrastructure was an implementation detail. Wilson, his team, and their agents shipped code, Ferndesk grew, and customers were happy. But as larger companies with large product surfaces began to depend on Ferndesk to host and maintain their help centers, reliability issues with Ferndesk's underlying infrastructure provider became more visible and more frequent.

If Ferndesk goes down, tickets pile up

Ferndesk had run on Railway for years. Wilson preferred building on a platform rather than a hyperscaler because it allowed their lean team to focus on their product and customers instead of ops overhead. "Our goal was finding a place where we could deploy all of our stuff and maintain one centralized view," Wilson recalls. "We can just spend more time building our application."

But with Railway, maintaining a simple DX started to come at the cost of reliability. Downtime that had once been a roughly quarterly event turned monthly, then weekly, then almost daily. "We kept having to stop and figure out whether a problem was on our end or Railway's," he says. "More often than not, it was Railway's. It felt like issues were happening almost daily."

A year earlier, that would have been an annoyance. With enterprise customers depending on Ferndesk to host their docs, it became an existential risk. "For every second that Ferndesk is down, our customers' support volume goes up, because people can't access their docs," Wilson says.

Ferndesk home/middle page. — The AI agent that keeps your help center up to date.

Agents did the migration in a few hours

Wilson didn't want to spend cycles migrating. He had a lot of services running, and reconfiguring all of them looked like weeks of work: environment variables, internal networking, whatever builds broke along the way, then DNS and wildcard SSL at the end. "The idea of spending days or weeks migrating was a nightmare," he says.

But "reliable enough" wasn't cutting it anymore. Wilson made the decision to urgently switch their infrastructure to Render. The Ferndesk team was already looking to simplify how they managed infrastructure. "We were trying to refine some of our processes, including how we handle environment management," he says. "So I thought, why not just try these CLIs and MCPs and see how far we could get?" He installed the Render and Railway MCPs, handed the job to Codex, and let it work.

“The thing I'm most grateful for about Render is the reliability, because I'm able to sleep at night.”

Wilson, Founder at Ferndesk

Wilson Wilson (@euboid) on X

Codex replicated Ferndesk's stack on Render: nine services across Docker and Node runtimes, plus a managed Valkey instance for Redis, all on one platform. It moved the environment variables over securely and kept them in sync across services. Private networking and autoscaling were there by default. Agents did the work Wilson had been dreading and allowed Ferndesk to fully migrate to Render in less than a day.

"In a few hours, it had unified our env management, configured all our Render instances, and fixed broken builds," he wrote afterward. "All we had to do was update our DNS." The setup was working that evening. He switched DNS the next morning, and Ferndesk has been on Render since.

Handing the migration to Codex was the start of a pattern. The way Ferndesk runs now follows the same instinct: let agents do the work. Codex reads Render's metrics, deployments, and logs through the API and debugs issues directly, without Wilson needing to open a dashboard. "The API is fantastic, and it plays really nicely with Codex," he says.

Infrastructure that lets you sleep

Ferndesk's on-call calmed down. "Now when something goes wrong, we can confidently say it's almost certainly an issue on our end," he says. "And when we're not sure, we create an incident report and send it to Render support. In minutes, they tell us what's going on, and we're unblocked."

For Ferndesk, the time that used to go into firefighting outages now goes into the product. And for a founder whose software sits inside other companies' support operations, it comes down to one thing.

As Wilson puts it: "The thing I'm most grateful for is the reliability, because I'm able to sleep at night."