Sites and apps
How to deploy a Bun app and put it online
In short
To deploy a Bun app, keep the lockfile next to package.json: bun.lockb or bun.lock is the signal that dependencies should be installed and the app started with Bun instead of Node. The server has to listen on the port from the PORT environment variable and on the 0.0.0.0 address; in Bun.serve you pass it as the port field. After that you upload the code as an archive or import it from GitHub, and Netrun installs the dependencies, starts the app and gives you a public HTTPS link.
The usual way to deploy a Bun app is to rent a machine, install Bun on it (most system package managers still do not ship it, so it comes from a separate install command), keep the process alive across reboots, put a reverse proxy in front and get a certificate. Fewer platforms understand Bun out of the box than Node, so a lot of guides end up describing a manual setup on a VPS.
Netrun takes that part away. You upload the folder with your code, the platform sees the Bun lockfile next to package.json, installs the dependencies, starts the app and gives you a public HTTPS link. No server, no proxy, no certificate to renew. Below is what to check in the project so the very first publish ends with a working link.
Keep bun.lockb next to package.json#
The Bun lockfile, bun.lockb in older versions or the text bun.lock in newer ones, is the main signal that the project should be installed and started with Bun. If you have no lockfile, a mention of Bun inside package.json also counts: a start script that begins with bun, or an engines field naming bun. With neither of those the project goes through as a plain Node app on npm, so the simplest fix is to run bun install once on your machine and ship the resulting file with the code.
Leave one clear start command#
Add a start entry to the scripts section of package.json, for example bun run index.ts or bun run src/server.ts. One command instead of three ways to launch the app removes any doubt about the entry point. If the project also happens to run on Node, that is fine: what matters is that the start command is single and obvious.
Read the port from the environment#
A web server must listen on the port from the PORT environment variable and on 0.0.0.0 rather than 127.0.0.1. In Bun.serve the port goes into the port field, and the hostname field takes 0.0.0.0. A port hard-coded as a number is the number one reason a link returns nothing: the app listens somewhere other than expected.
Check your framework#
Elysia works, Hono works, and so does plain Bun.serve with no framework at all. What matters is not the framework but that the app listens on the right port. Elysia takes the port in its listen call, Hono exports an object with fetch and port fields. In both cases take the value from PORT instead of a constant.
Leave node_modules out of the archive#
Do not put node_modules or a prebuilt bundle into the archive: dependencies are installed during publishing from package.json and the lockfile. The upload stays small and the package versions match the ones you pinned. Keys, tokens and database connection strings do not belong in the code either. Netrun asks for them during setup and passes them in as encrypted environment variables.
Upload the code and grab the link#
Bring the project in as a ZIP archive or import it from GitHub, private repositories included. Netrun installs the dependencies, starts your Bun app and issues a public HTTPS address. Logs and publishing status stream into your dashboard in real time, so a startup error shows up right away instead of as a silent page.
Your Bun app ends up at an ordinary link you can send to anyone, with no rented server and no certificate to set up. On the free plan a site sleeps while nobody uses it and wakes up on its own when someone opens the link, so the first visit after a pause is slightly slower. If the service has to answer without that delay around the clock, the Pro plan fits better. Try Netrun.
Common questions
How does the platform know to run the project with Bun instead of Node?
By the lockfile. A bun.lockb or bun.lock next to package.json means dependencies are installed and the app is started with Bun. If there is no lockfile, a mention of Bun inside package.json counts too: a start script beginning with bun, or an engines field. With none of those signals present the project is treated as a regular Node app. You never have to pick a runtime by hand in the dashboard.
What if the project has no bun.lockb?
Run bun install once on your own machine and ship the lockfile it creates next to package.json. It also pins package versions, so the build on the server matches the one you tested. If you cannot produce the file, name Bun in package.json instead: a start script such as bun run index.ts works as a signal too. With neither in place the project is installed with npm and started as a Node app.
Do Elysia and Hono work?
Yes, both work, and so does an app written directly against Bun.serve. The single requirement is the same for all of them: listen on the port from the PORT environment variable and on 0.0.0.0. No framework specific configuration is needed.
Why does my app not open at the link?
Most often the port is written into the code as a number, or the server listens on 127.0.0.1 instead of 0.0.0.0, which nothing outside can reach. The second common cause is a crash at startup, for example because a secret was never set. Both are visible in the logs in your dashboard within seconds of publishing.
Do I need to compile TypeScript before uploading?
No. Bun runs .ts files directly, so no separate build step is required for that. If your project does have its own build, keep a single start command that does whatever it needs to do. Do not upload the compiled output, it is produced during publishing.
Will a Bun app run around the clock?
A Bun site or API on the free plan sleeps while idle and wakes on its own at the first request, so the link keeps working; only the first visit after a pause is a little slower. A background script with no public address gets three days of free runtime, after which the project is switched off while the code and settings stay in place. Non-stop operation with no pauses is what the Pro plan is for.
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.
How do I update the code of a project that is already published?
Open the project and upload a new version or update it from GitHub. The link stays the same, and your data is kept as long as it lives in persistent storage — the /data folder or a volume from your compose file.