Sites and apps
How to deploy a Deno app without your own server
In short
To deploy a Deno app you need a machine that keeps it running and an address with HTTPS. The simplest way is to upload the source code to Netrun: the platform sees the deno.json in the project root, pulls the dependencies and returns a public HTTPS link. In your code, read the port from the PORT environment variable with Deno.env.get("PORT") and listen on 0.0.0.0 rather than localhost. The Deno-specific part is permissions: the start command has to grant network and environment access (--allow-net and --allow-env), otherwise the app dies on startup with a "Requires net access" error.
The usual way to self-host Deno is to rent a server, install Deno on it, work out how to keep the process alive after a reboot, put a proxy in front of it and get a certificate. Deno adds one more thing on top of that. It grants a program no access by default, neither to the network nor to environment variables, so the flags you type by hand in your terminal have to be carried over carefully into a service file on the server.
Netrun takes that part away. You upload the source code, the platform reads deno.json, works out that this is Deno, downloads the dependencies, starts the app and gives you a public HTTPS link. Below is what to check in your project before publishing so that the link works on the first try.
Put deno.json in the project root#
A deno.json (or deno.jsonc) in the root is what identifies the project: it tells us this is Deno rather than Node.js, and it holds the start task and the import map. Keep it in the root of the archive, next to the main file of the app, not inside a nested folder, otherwise the language is detected incorrectly. Even for a single-file project with no external libraries it is worth adding, because it defines how the app is started.
Read the port from the environment#
We set the port to listen on and pass it in the PORT environment variable, so take it with Deno.env.get("PORT") instead of writing a number by hand. Listen on 0.0.0.0, not on localhost: localhost is only visible to the app itself from the inside, and the public link stays blank. In Deno.serve this is the options object with port and hostname, where you plug in the value from the environment. A hard-coded port is the number one reason a deployment succeeds but the page never opens.
Grant permissions in the start command#
Deno will not let a program reach the network or read environment variables until you allow it explicitly with flags. Describe the start command as a start task in deno.json and list the permissions it needs: at minimum --allow-net to accept requests and --allow-env to read the port and your secrets. Without them the app builds and then dies on startup with an error like "Requires net access", which shows up on the first line of the logs in your dashboard. If you do not want to work out the exact list right away, --allow-all is fine to begin with and can be narrowed later.
Leave the dependency cache out of the archive#
Deno downloads libraries during the build itself, from the imports in your code and the import map in deno.json. So there is no need to include the cache folder, a vendor folder or node_modules: they are heavy, they go stale after the first edit and they change nothing. A deno.lock file is worth including, because it pins the same library versions you tested locally.
Move keys into secrets#
Read tokens, third-party API keys and database connection strings from environment variables with the same Deno.env.get you use for the port. During project setup Netrun asks for these values and passes them in encrypted, so they never sit in the archive or in your GitHub repository. Remember that reading the environment needs the --allow-env flag, otherwise the app crashes the first time it looks up a key.
Upload the code and take the link#
Bring the project in one of two ways: a ZIP archive with the sources, or an import from a GitHub repository, including a private one. You do not need Deno installed anywhere or a build prepared in advance, because the build happens on our side, and its status and logs are visible in your dashboard in real time. When it finishes you get a public HTTPS link you can open and share, and it stays the same when you update the code.
Your Deno app is now online without a rented server, a service file or a manual certificate. The free plan gives you one project: a site on it sleeps while nobody uses it and wakes up on its own when the link is opened, so the first visit after a pause is a little slower. If the project is a bot or a background script rather than a site, there is nothing to wake it, so on the free plan it runs for three days and after that it needs the Pro plan with round-the-clock uptime. Try Netrun.
Common questions
My Deno app starts, so why does the link not open?
It is usually one of three things: the app was never granted network access with --allow-net, the port is a number in the code instead of a value read from the PORT environment variable, or the server listens on localhost instead of 0.0.0.0. Check the start task in deno.json and the line where the server is created. The logs in your dashboard show exactly how the startup ended, so there is no need to guess.
How do I pass the right port to Deno.serve?
Deno.serve takes an options object: set port to the value from the environment, for example Number(Deno.env.get("PORT")), and set hostname to 0.0.0.0. If you skip that, Deno.serve falls back to its own default port and nothing from the outside can reach the app.
What does the "Requires net access" error mean?
That is Deno telling you the program tried to reach the network or read the environment without permission. The fix is in the start command, not in the code: add the flags you need, --allow-net for the network, --allow-env for environment variables, --allow-read and --allow-write if the app works with files. Upload the updated code afterwards and the project rebuilds on the same link.
Can I use npm packages in a Deno project?
Yes. Deno can import npm packages directly, and we download them during the build, so node_modules does not belong in the archive. If the project is written as a regular Node.js app with a package.json, it also publishes fine, it is simply detected as Node.js. Do not keep both manifests in the same root, because then language detection becomes unpredictable.
How do I run a Deno script on a schedule?
There is no separate scheduler on the platform, so the schedule lives inside the app: usually an endless loop that does the work and then sleeps until the next run. A project like that counts as a background script. It never sleeps, but there is also nothing to wake it, so on the free plan it runs for three days and needs the Pro plan to keep going.
Are files written by the app kept between deployments?
They are kept if you write them into the persistent project folder, /data. Files written next to the code are recreated on the next publish. Writing needs the --allow-write permission, and the contents of the folder are visible in your dashboard on the Data tab, where files can be downloaded, uploaded or deleted.
Which languages and technologies are supported?
Python, Node.js, Go, Rust, Ruby, PHP, Java, .NET, Deno, Bun, Elixir, static sites and bash scripts. You can bring your own Dockerfile or docker-compose, but more often the stack is detected from your code automatically.
Do I need to know how to work with Docker?
No. Netrun detects which language your project uses and builds it for you. If you already have a Dockerfile or docker-compose, we support them, but you do not need to write them specially.
Where do I set tokens and other secret values?
Every project has a Secrets tab where you set the values from your code — for example the token from BotFather. We store them encrypted: you can see the variable names, but the values are shown to no one, including you.
Why does my website sometimes sleep?
On the free plan, websites sleep after being idle and wake up in a couple of seconds on the first request. On the Pro plan your project runs without sleeping.