Deno
Deploy a Deno app on Ruust: built with Nixpacks, run with explicit permissions, and served on HTTPS with automatic TLS.
Deno is a secure runtime for JavaScript and TypeScript with a built-in HTTP server. Ruust builds your repo with Nixpacks, and it is Nixpacks (the build host running its Deno provider), not Ruust itself, that auto-detects Deno, so there is no config to write for a standard app. If you would rather control the build yourself, add a Dockerfile at the repo root and Ruust builds that instead. Your Egg is a long-running server with no cold starts, so Deno.serve, background tasks and websockets all keep running.
Deploy it
- Push your app to a Git repo.
- In the dashboard, choose New Egg and connect the repo (Eggs live in a Coop, so pick or create one).
- Pick a size and a region (London or Virginia, or your own byo host), then lay the Egg.
- Watch it incubate (build) then hatch (deploy). Once hatched it is live on its
.ruust.runURL.
Pin the start command with a Procfile at the repo root. On the Nixpacks path, the web: line is honoured by the Nixpacks build, which reads it and bakes it into the image as the start command at build time (it is not read by Ruust itself, and is ignored when you supply your own Dockerfile). Deno needs explicit permission flags, so grant --allow-net (and --allow-env if you read env vars, which you will for PORT).
web: deno run --allow-net --allow-env main.tsThe port
Ruust sets a PORT env var. Your app MUST listen on it and bind to 0.0.0.0, not localhost. Binding to the wrong address is the top reason an Egg builds but never hatches: the health check cannot reach a server bound only to loopback. Deno.serve defaults to 127.0.0.1, so set the hostname explicitly.
Deno.serve(
{
port: Number(Deno.env.get("PORT")) || 8000,
hostname: "0.0.0.0",
},
(_req) => new Response("Hello from your Egg"),
);Environment variables
Set env vars on the Egg. They are available at both build and run time, encrypted at rest, and never printed in logs. Read them with Deno.env.get("MY_VAR") (which needs the --allow-env permission). Because Deno has no separate client bundle by default, there is no public prefix to worry about: only bake a value into client-served assets if you deliberately do so at build time, and never put a secret there.