Deno Deploy Killed My Start Page

Deno Deploy Killed My Start Page. My small web app disappeared overnight when Deno Deploy Classic shut down with no automatic migration. Here's what happened, why it matters, and why I moved to Netlify.

Deno Deploy Killed My Start Page

Deno Deploy Killed My Start Page

A little over a year ago I made a small thing. It was a start page -- a web page with tiles for the URLs I use most. You set it as your browser's home page, so it's the first thing you see every time you start the browser. Click a tile, you're there. Simple. Useful. The kind of thing that takes 20 minutes to build and saves you 15 minutes a day forever. No searching through bookmarks, no trying to remember what was where. It just worked.

It was a couple of static files. HTML, CSS, a bit of JavaScript. No backend, no database, no build step, no framework. Nothing fancy. Exactly the kind of thing you'd throw on a free hosting platform and forget about.

I deployed it on Deno Deploy in May 2025. The URL was startpage.deno.dev. It ran for over a year without any attention from me. That's the best kind of software: the kind that works so reliably you forget it exists.

Yesterday I opened the URL and it was gone.

The Shutdown

Deno Deploy Classic was shut down on July 20, 2026. Not deprecated -- shut down. The old platform at dash.deno.com was turned off. The new platform at console.deno.com is a completely different system.

Here's the part that's hard to believe: projects were not automatically migrated. Nothing transferred. No apps, no environment variables, no data, no custom domains. The migration plan was to manually recreate everything from scratch.

Imagine if your hosting provider decided to replace their servers and the migration plan was "we deleted your files, please re-upload them to the new servers, which work differently, and by the way the old servers are already off." That's what happened.

Why It Matters

The immediate problem is that my app disappeared. But the deeper problem is about trust.

When you deploy something to a platform, you're making a bet. You're betting that the platform will still be there tomorrow. Not because they promised -- platforms don't promise that -- but because the entire value proposition of a hosting platform is that you don't have to think about it. That's what you're paying for (even when it's free). You're trading control for convenience, and the convenience is "I don't have to worry about this."

Deno Deploy broke that trade. They took away the convenience and kept the lack of control. The worst of both worlds.

The Migration That Wasn't

I tried to redeploy on the new platform. It didn't work. The GitHub integration had issues. The deployctl CLI was retired. The build system expected everything to happen inside Deno's environment, which broke my existing workflow.

So I moved it to Netlify. New URL: dashpage.netlify.app. The deployment took a minute. Connect repo, configure build, deploy. Done. A couple of static files -- that's all it is. Netlify is built for exactly this.

I should note that I've used Netlify before -- I even wrote about choosing it for my main site. The experience was smooth then, and it's smooth now. That consistency is exactly what you want from a platform.

The Pattern

What happened to Deno Deploy wasn't a one-time mistake. It was a trajectory. The signs were there:

  • 2023: 35 regions, marketed as "global edge"
  • January 2024: Dropped to 12 regions
  • December 2024: Dropped to 7 regions
  • January 2025: Dropped to 6 regions
  • Late 2025: Rushed Deploy V2 relaunch
  • March 2026: Layoffs
  • July 20, 2026: Classic platform hard shutdown, no auto-migration

When a platform is shrinking -- fewer regions, fewer features, fewer employees -- the writing is on the wall. The shutdown wasn't a surprise to anyone paying attention. But most users aren't paying attention. They're using the platform, not tracking its corporate trajectory. That's the whole point of using a platform.

Features That Didn't Survive

The new platform didn't just fail to migrate old projects. It also dropped features that people depended on:

  • Deno Queues -- gone entirely, no replacement
  • KV data -- requires manual email to support for migration
  • Legacy serve() API -- apps using it silently fail with timeout errors
  • deployctl CLI -- retired
  • Free tier -- severely restricted; one user reported a static site consuming 10.5 GB/hour of RAM

The community response has been vocal. A GitHub issue documents the problems. Blog posts tracking Deno's decline hit the top of Hacker News. The CEO responded. The community wasn't convinced.

The Lesson

The lesson isn't "don't use Deno Deploy." Well, actually, it kind of is. But the broader lesson is about what you should expect from a platform.

A platform that gives you a URL has a responsibility to that URL. Not a legal responsibility -- read the terms of service, they cover themselves. But a practical responsibility. URLs are how the web works. When someone bookmarks your URL, or sets it as their homepage, or builds it into their daily routine, that URL has value. Killing it without a redirect destroys that value.

URLs should be forever. Or at least, they should redirect to wherever the new forever is. If you're going to kill a platform, give people a bridge. Give them time. Give them a migration path that doesn't require a support ticket and a prayer.

The platforms I trust are the ones that have been around long enough to know how to handle endings. Netlify has migrated infrastructure multiple times without leaving users in the dark. Cloudflare Pages evolved from Pages to Workers without breaking URLs. Even GitHub Pages, which has been around since 2008, has never just turned off someone's site.

My start page is back at dashpage.netlify.app. It still saves me fifteen minutes a day. But I've learned something about where to put things I depend on.

Put your small, useful things on a platform that respects the URL. That's the whole deal. If they can't respect the URL, nothing else matters.

Previous
Back to Golang: Why I Switched From Static to Dynamic Again
Next
Ork: SSH Server Automation in Go

Keep Reading

Explore more articles and insights

Ork: SSH Server Automation in Go

Ork: SSH Server Automation in Go

Read Article
Back to Golang: Why I Switched From Static to Dynamic Again

Back to Golang: Why I Switched From Static to Dynamic Again

Read Article
Associations and Eager Loading in Go — Without GORM

Associations and Eager Loading in Go — Without GORM

Read Article
View All Blog Posts