Val Town Is Winding Down. Code Goes Read-Only December 10 and Everything Stops January 10. Here Is the Migration Order I'd Follow.
Val Town announced on November 10 that it is shutting down. Steve Krouse's letter to the community gives four dates: new signups and upgrades stopped that day, code becomes read-only on December 10, all remaining services stop on January 10, 2027, and the company plans to open source Val Town on February 1, 2027. If you have a cron job, a webhook receiver or a small API running there, you have about a month before you can no longer edit it and two months before it stops answering.
What the letter says
The stated reason is short. Krouse writes that the company "couldn't compete in the cloud computing space." He gives no revenue figures, no user counts and no acquirer, and the letter thanks the team and investors by name without saying where anyone is going. Val Town ran for four years.
On money, the letter says billing is paused as of the announcement and existing subscriptions keep running for free. Customers who prepaid for an annual plan will get a partial refund. The letter does not give the formula, the method or a deadline for it, so if you are on an annual plan I would email support@val.town now and get the number in writing.
The timeline table has one detail worth reading twice. The December 10 row says read-only mode does not include SQLite and blob storage. I read that as your data stores staying writable until January 10 while your code freezes, but the letter does not spell it out and I would not plan around my reading. Val Town's migration docs do say vals keep running until January 10.
What the migration docs give you
Val Town published guides for four targets: Cloudflare, Vercel, Netlify and Render. Each one has the same set of sub-guides, covering code, environment variables or secrets, SQLite, blobs, AI calls, scheduled jobs, email, access control and domains. There are also separate pages for storing your code on GitHub and for redirecting *.val.run URLs. I read the overview page, not every sub-guide, so I can tell you the guides exist but not how well each one works.
Two pieces of advice on that overview page stood out. The first is to redirect a val.run URL only after the replacement is verified and its data is synced, and to update webhook URLs directly with each provider. The second is about the runtime. Val Town runs on Deno, and the docs recommend moving to Node, Bun or a provider runtime such as Cloudflare Workers or Vercel Functions. They say Deno's core maintainers won't support it beyond October 2027. That is Val Town's claim on its own docs page and I have not confirmed it against a Deno announcement, but it tells you where Val Town thinks the safe ground is.
The page also includes a prompt you can hand to a coding agent, which asks the agent to install Val Town's plugin or MCP server, pick a platform and propose a plan. That is a reasonable way to draft the plan. I would still do the cutover by hand.
The open source date comes after the shutdown
Open sourcing is scheduled for February 1, 2027, three weeks after the services stop. The letter does not name a license, say which parts of the system will be released or say whether the result will be self-hostable. So self-hosting is not a way to avoid migrating. Even if the release turns out to be complete, it arrives after your vals are already off.
What I'd actually do
I would migrate in the order of what fails without telling me, not in the order of what is easiest to move.
- Inventory this week. List every val with its type: HTTP endpoint, cron, email handler. For each one, write down who calls it. A webhook from Stripe or GitHub is the dangerous kind, because when the URL dies the sender retries for a while and then gives up quietly.
- Get the code into Git before December 10. Read-only does not delete anything, but I want my copy in a repo I control while I can still fix things in place.
- Move data next. Export SQLite and blobs using the guide for your target, then compare row counts on both sides. Do it early enough that you can run it a second time right before cutover.
- Move crons one at a time and let old and new run side by side for a day if the job is safe to run twice. If it is not safe to run twice, disable the old one first and accept a short gap.
- Change webhook URLs at the provider, then set the
val.runredirect as a backstop. The docs say to redirect only after verifying, and I agree. A redirect to a broken endpoint hides the failure. - Calendar January 3 as your own deadline. A week of slack before the real one costs nothing.
As for where to go, I would pick whichever of the four hosts I already have an account and a deploy habit on. For a single cron and a webhook, the differences between them are smaller than the cost of learning a new one under a deadline.
Where this could be wrong
Sixty-one days with paused billing, four migration guides and a promise to release the code is a generous shutdown. Meta gave Conductor's cloud users about two weeks earlier this month. I am not arguing that Val Town treated people badly, and I would use a small platform again.
The part I hold onto is narrower. Val Town was pleasant because the code, the scheduler, the database and the URL all lived in one place, and that is the same reason leaving takes a ten-item guide per host. For anything that takes money or receives webhooks, I now keep the code in my own repo from day one and I write down, before I ship, where it would run if the host disappeared. If your vals are toys and experiments, none of this applies. Copy the ones you like and let the rest go.
Author
Lukas
@lukcombinator