Deno Joined Cloudflare: Should You Self-Host on a VPS?

Cloudflare bought Deno in late 2025, and if you run a couple of small JavaScript apps, the practical takeaway is simple: Deno itself — the open-source runtime you install with one command — isn't going anywhere, and it runs perfectly well on a plain VPS you control. The acquisition is about Cloudflare's own platform, not about trapping the runtime behind a paywall.

So the real question isn't "is Deno safe to use?" It's "where should my small app live — on my own box with the Deno runtime, or on a managed edge platform where someone else handles the servers?" Both are legitimate. The answer turns on how much you want to own versus how much you want to outsource.

Here's the honest breakdown, with the lock-in costs named out loud.

What the Cloudflare–Deno deal actually changes for you

For most people running small apps, the acquisition changes almost nothing today — the Deno CLI, Deno Deploy's open bits, and the runtime stay open source and installable anywhere. Cloudflare's stated goal is to use Deno's engineering to make their self-hosting story for Workers and Durable Objects less painful, not to pull the rug on the standalone runtime.

What's worth watching is direction. Deno's hosted product, Deno Deploy, will increasingly be shaped around Cloudflare's network. If you've built on Deno Deploy's platform-specific features — its KV store, its queues, its cron bindings — expect that story to converge with Cloudflare's over time. That's normal after an acquisition, but it's exactly the kind of thing that quietly deepens lock-in.

The clean line to draw: the runtime is portable; the platform is not. Code that uses standard web APIs and Deno's own CLI runs identically on your laptop, a VPS, or an edge platform. Code that reaches for a proprietary binding does not.

Can you really run Deno on your own VPS?

Yes — Deno runs on a small Linux VPS with no exotic setup, and for most small apps it's genuinely less fuss than Node plus a toolchain. You get TypeScript, a formatter, a linter, a test runner and a dependency system in one binary.

Install takes one line:

• Install the runtime: curl -fsSL https://deno.land/install.sh | sh
• Run your app: deno run --allow-net --allow-read main.ts
• Keep it alive: wrap it in a systemd unit so it restarts on crash and boot

A minimal systemd service is the part people skip and regret. Create /etc/systemd/system/myapp.service with your exec line, Restart=always, and a dedicated non-root user, then systemctl enable --now myapp. Put Caddy or Nginx in front as a reverse proxy so you get TLS and a clean public port. Caddy is the shortcut here — it handles certificates automatically, so you're not hand-rolling renewals.

One thing to respect: Deno's permission flags are a real security feature, not ceremony. Grant --allow-net, --allow-read and --allow-env narrowly instead of reaching for --allow-all. On a shared box this is the difference between a compromised dependency reading one config file and reading your whole home directory.

Self-host vs managed edge: the real trade-off

Self-hosting on a VPS gives you ownership and predictable pricing; managed edge gives you global speed and zero server maintenance — pick based on your traffic shape and your appetite for ops.

The honest comparison:

Take a position: if your app has a handful of regular users, talks to a database you also host, or does anything long-running — a websocket server, a background worker, a Discord bot, an internal dashboard — a VPS is the better home. You get the full process model, no per-request accounting, and a bill that doesn't move. Edge platforms shine for stateless, read-heavy, globally-distributed traffic where a surprise spike must just absorb cleanly.

The lock-in costs nobody itemises

Lock-in on an edge platform isn't the runtime — it's the surrounding services your code quietly comes to depend on. That's where leaving gets expensive.

Watch for these dependencies creeping into your code:

• Proprietary storage: KV stores, Durable Objects, platform-specific blob storage. Migrating this data and rewriting the access code is the hard part, not moving the compute.
• Platform bindings: queues, cron triggers, environment injection and routing that only exist on that provider.
• Runtime quirks: execution-time limits and request-size caps that your architecture bends around, which then don't map onto a normal server.

You can hedge without giving up the convenience. Keep your business logic in plain TypeScript modules that only use standard web APIs. Put anything platform-specific — the KV call, the queue push — behind a thin adapter you could swap. Then "moving off" becomes rewriting one adapter and copying data, not untangling your whole app. This discipline costs an hour now and saves a week later.

One more quiet cost: observability. On managed edge your logs and metrics live in their dashboard. On your VPS you own them — which means you also have to set them up. A lightweight combo of journalctl for the systemd service plus something like Uptime Kuma for external checks covers most small apps without a monthly bill.

A sensible setup if you go the VPS route

For a small Deno app on a VPS, a tidy, boring stack beats a clever one: Caddy for TLS, systemd for process management, a firewall locked to ports 80/443/22, and automatic security updates.

A starter checklist you can work through today:

• Create a non-root user and run the app as that user, never as root
• Install Deno and pin the version so a surprise update can't break production
• Write a systemd unit with Restart=always and least-privilege permission flags
• Put Caddy in front for automatic HTTPS and a clean reverse proxy
• Enable ufw and allow only 22, 80 and 443
• Turn on unattended security upgrades for the OS
• Set up a daily off-box backup of your app data and a monitor that pings you if it's down

This is where the host you choose matters more than the runtime. You want a VPS with room to grow, EU data residency if your users are in Europe, and real people to ask when a config fights you. TPC Hosting keeps VPS pricing plain and hosts inside the EU, which keeps you on the right side of GDPR without extra paperwork. Our AI chat answers at any hour, and real engineers follow up during business hours — handy when a systemd unit or reverse-proxy rule won't cooperate at 1am. Moving an existing app over is covered by free migration, and if it doesn't suit you, there's 30 days to back out.

Deno on a VPS isn't a downgrade from edge — it's a different deal. You trade global milliseconds for ownership, a flat bill and code that goes wherever you do. For most small apps run by one person or a small team, that trade is a good one.

FAQ