Val Town Is Shutting Down: How to Migrate AI Apps Without Losing Data or Jobs

Val Town announced on November 10 that it is winding down. Code becomes read-only on December 10, 2026, and apps stop running on January 10, 2027. If your AI workflow depends on it, migrate the database, schedules, credentials and incoming requests alongside the code.

The most expensive mistake would be treating a successful deployment elsewhere as a completed migration. A copied app can render its homepage while quietly missing its nightly job, charging the wrong model account or continuing to accept writes into its old database.

Val Town shutdown dates and billing

The official announcement gives this timeline:

Change	Date
New signups and plan upgrades stop	November 10, 2026
Code becomes read-only, excluding SQLite and blob storage	December 10, 2026
Remaining services end	January 10, 2027
Planned open-source release	February 1, 2027

Billing is paused, existing subscriptions continue to be serviced for free during the wind-down, and prepaid annual plans receive a partial refund. The planned open-source release comes after the service shutdown, so it is not a reason to postpone moving a working application.

Choose a destination from the dependencies

Val Town's replacement guide calls Cloudflare its closest feature match and also points users toward Vercel, Netlify and Render. That is a starting point for investigation rather than a promise that every API transfers unchanged.

Before choosing, make a small inventory of what each val actually uses. For an AI support assistant, that might include an HTTP endpoint, a SQLite conversation table, uploaded files, a model provider and a nightly cleanup job. Add authentication and inbound email if they exist; do not assume they are part of the frontend.

Existing workload	What should drive the choice
Small endpoint with SQLite, files and scheduled work	Compare integrated services and the amount of adapter code required
App already moving into a Next.js project	Evaluate Vercel alongside its database and email integrations
Long-running server or unusual native dependency	Verify the target runtime supports the actual process and libraries
Mostly static UI with a small backend	Separate the UI move from the data and scheduled-job decisions

This approach avoids choosing a familiar host first and discovering later that the application depends on an incompatible runtime behavior.

Migrate one AI workflow without changing its model

Keep the first migration boring. In the support-assistant example, preserve the model, system instructions, output format and user-visible behavior while moving the hosting. Replacing both the model and the runtime makes a regression much harder to diagnose.

Val Town's AI migration guidance distinguishes a direct provider SDK, Cloudflare AI Gateway and Workers AI. A gateway is routing infrastructure, not a model. Check the supported provider, credentials, billing account and any logging or caching settings before sending production traffic through it.

Build a small acceptance set from non-sensitive examples: a normal request, a long response, a cancelled stream, malformed tool output and a provider error. Compare the old and new app's behavior, not just their HTTP status. Keep provider keys on the server and preserve the usage controls that stop a public endpoint from becoming an unlimited inference bill.

These are proposed migration checks, not results from a hands-on test of your app.

Protect the database during cutover

The SQLite migration reference warns that an account-global database can contain tables from unrelated apps. Identify the actual tables, relationships and records needed before exporting anything.

For the support assistant, exporting the conversations but losing user IDs would leave apparently complete data that cannot be attached to the right accounts. Preserve schema and identifiers, then compare row counts and representative records after a rehearsal import. Keep private exports outside source control and chat.

Pause writes and scheduled jobs during the final consistent export. The destination should become the sole writer only after the imported state is verified. A backup does not by itself provide a safe rollback once the new database has accepted fresh messages; a reversal also needs a plan for those new writes.

I would rehearse this with a disposable destination before choosing a cutover window. It is cheaper to discover an incompatible query there than after customers start adding data.

Move requests last, and watch for duplicate work

The documented val.run redirect behavior is important: setting a redirect immediately stops the original val from receiving requests. Paths and query strings are preserved by default, but this can be disabled.

Use redirects only after the new endpoint and its data are ready. Webhook providers may not follow redirects, so update their configured destination directly and verify a representative delivery. Custom domains need their own DNS changes rather than a val.run redirect.

For the nightly cleanup job, give one scheduler ownership of execution. Verify the new job with disposable records, disable the old schedule and check the first real run. Running both “just to be safe” can double side effects, especially for jobs that send emails, charge accounts or call paid models.

Before calling the migration complete, check an existing login, an incoming event, a model response, a file lookup and a scheduled action. Keep the source backup until the new workflow has demonstrated that it can operate independently.

The shutdown makes platform dependencies visible. Use the move to document which service owns each piece of state and each recurring action, so the next hosting change is a bounded engineering task rather than a search for forgotten behavior.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product changes and difficult engineering trade-offs into clear stories developers can use.

Book a 30-minute call.