Appwrite Deno Functions as a Deno Deploy alternative_
Deno Deploy shuts down in six months. Appwrite is open source. Cloud and self-hosted stay independent, so you can keep writing Deno without a vendor host.
On October 9, 2026, Ryan Dahl wrote that the Deno team is joining Cloudflare. Deno Deploy keeps running for six months, then it shuts down. Paying customers are pointed at Cloudflare Workers.
If you shipped TypeScript on Deploy, you need a new host. Workers is the official offer. It is not the only one.
This announcement has no effect on Appwrite users. Appwrite Cloud and self-hosted Appwrite do not run on Deno Deploy. Functions run in containers we maintain. Both products are the same open-source stack, free of that vendor lock.
You can move a Deploy service to Appwrite Functions on Deno 2.6, keep TypeScript, and run it on Cloud or on your own machines. You change the handler. You do not take a dependency on Deno Deploy, and you do not have to adopt Workers.
We did not build Appwrite as a Deno host. Deno is one runtime among Node.js, Bun, Python, Go, and others. You can land on Deno today, and leave it later, without a second vendor migration.
Why we built Appwrite to stay self-sustained
We built Appwrite because too many products were assembled from vendors we did not own. The first time a hosted layer disappeared, the lesson was permanent. The piece you do not control is the piece that can take the rest of the work with it.
Our conviction has not changed. Appwrite is open source. It should stay self-sustained. Auth, databases, storage, functions, and hosting should live in one stack you can read, run, and keep. We use third parties where that is reasonable. We do not rent the parts that would take the product down if that company changed direction.
That is why the Deno team joining Cloudflare changes nothing for people already on Appwrite. Cloud infrastructure and self-hosted installations are independent of Deno the company and of Cloudflare. There is no Deploy account in the path, and no lock that would force a migration this week.
Deno Deploy is the failure mode we refused to build. The runtime is open source. The host was not. When the company puts its energy into Cloudflare instead of Deploy, the hosted layer has no remaining job. Official runtime work ends after a year of patches. JSR survives. Your fetch handler does not get the same courtesy.
Workers can be the right move if you already want that model. Their joint post is clear about that direction.
We would rather you run an open-source function in a container we maintain, next to data you control.
What you get if you land on Appwrite
An Appwrite function has its own URL, variables, permissions, and deployments. It runs in an Open Runtimes container. You trigger it over HTTP, the SDK, a platform event, or a schedule.
Cloud currently has deno-2.0 and deno-2.6. Self-host if you want more versions, or the whole product on your machines. Git deploy and the local CLI use the same image. Auth, Databases, and Storage are already in the project.
Most Deploy apps are a fetch handler. Appwrite wants a default export that uses req and res. The rewrite is the wrapper.
export default async ({ req, res }: any) => {
if (req.method === "GET") {
return res.text("Hello, World!");
}
return res.json({ ok: true, body: req.bodyJson });
};
Create a function on deno-2.6 from the quick start, copy your modules, map the request, and keep Deploy up until you have seen traffic. If the project was a frontend, use Appwrite Sites.
You do not have to stay on Deno because the old host was Deno. Move that one function to Node, Bun, or Python if Deno was only the host. The project stays put.
Trying Appwrite Deno Functions
If you already run Appwrite, this week is a non-event. Your Cloud project and your self-hosted instance keep running.
If you are leaving Deploy, you have six months to move a handler. Create a function, pick Deno 2.6, and deploy. Appwrite is open source, so the same stack is on Cloud or on your own machines.
