Move from Node.js to Bun.sh

[SashaGoncharov19]

What problem will this feature address?

Currently, the project runs on Node.js and uses npm for package management. While this stack is standard, it presents a few limitations regarding performance and developer experience:
npm can be slow when resolving and installing dependencies, which increases setup time for contributors and build times in CI/CD pipelines.
Node.js, while mature, generally has slower startup times and higher memory overhead compared to newer runtimes.
Node.js often requires a significant number of external dependencies to handle tasks like bundling, transpiling, and testing. This adds complexity to the project configuration.

Describe the solution you'd like

I propose migrating the project runtime and package manager to Bun.

Bun is a drop-in replacement for Node.js that is significantly faster.
bun install is orders of magnitude faster than npm, which would speed up deployment builds and local development setup. Bun has a built-in bundler, test runner, and native TypeScript support. This would allow us to remove external dependencies and simplify the codebase/configuration files. Bun offers faster startup times and lower memory usage, which is ideal for a self-hosted PaaS solution like Dokploy where resource efficiency is key.

Describe alternatives you've considered

no alternatives

Additional context

No response

Will you send a PR to implement it?

Maybe, need help

[tonytkachenko]

The benefits are described well, but there are significant risks and limitations to consider:

1. Production Stability

Bun is still maturing (v1.0 released October 2023) compared to Node.js's 15+ years of battle-tested production use. The npm ecosystem compatibility remains incomplete - many packages are untested with Bun, and native modules along with Node.js internals may behave differently, leading to unexpected runtime issues.

2. Dokploy-Specific Risks

PaaS infrastructure like Dokploy relies heavily on child processes, Docker APIs, and system calls - areas where Bun is less proven. There's significant risk of breaking existing user deployments, and database drivers may have subtle incompatibilities.

3. Performance Reality

Install speed improvements only affect development setup and CI pipelines (which can be cached). Runtime performance gains are minimal for PaaS workloads, which are predominantly I/O-bound (Docker operations, database queries, network calls). The marginal memory savings don't justify the substantial migration cost and risk.

4. Migration Complexity

The migration carries high risk of introducing subtle bugs that only surface in production. User deployments may break if they rely on Node.js-specific behavior, requiring extensive testing of all functionality. The transition period demands maintaining compatibility with both runtimes, significantly increasing CI/CD pipeline complexity and expanding the testing matrix, which adds substantial ongoing maintenance overhead to the project.

5. Community & Ecosystem

Bun's smaller community results in slower issue resolution and fewer troubleshooting resources. Contributors familiar with Node.js may struggle with Bun-specific issues, and most documentation and examples remain Node.js-centric, creating additional friction for development and onboarding.

Better Alternatives

• pnpm: several faster than npm, full compatibility, production-proven. The project is already uses pnpm
• Node.js 24+: Recent performance improvements without ecosystem risk

My recommendation do not migrate. Risk/reward ratio unfavorable for production PaaS.

[SashaGoncharov19]

PaaS infrastructure like Dokploy relies heavily on child processes, Docker APIs, and system calls - areas where Bun is less proven. There's significant risk of breaking existing user deployments, and database drivers may have subtle incompatibilities.

Install speed improvements only affect development setup and CI pipelines (which can be cached). Runtime performance gains are minimal for PaaS workloads, which are predominantly I/O-bound (Docker operations, database queries, network calls). The marginal memory savings don't justify the substantial migration cost and risk.

Bun's smaller community results in slower issue resolution and fewer troubleshooting resources. Contributors familiar with Node.js may struggle with Bun-specific issues, and most documentation and examples remain Node.js-centric, creating additional friction for development and onboarding.

Node.js 24+: Recent performance improvements without ecosystem risk

My recommendation do not migrate. Risk/reward ratio unfavorable for production PaaS.

🤦‍♂️

Node.js can no longer be fast. It is totally slow, clumsy, and unable to provide the normal tools that developers need. Their updates are a total disgrace and not worth paying attention to. I won't even mention how they implemented native TypeScript integration. After so many years, they wrote such a piece of junk that a first-grader could do better.

[SteadEXE]

Feel free to fork Dokploy, if you think Bun would better suit your needs, but this kind of reply isn't helping you..
In a company we need stability over hype, and Bun isn't solving any major issue we are having, as @tonytkachenko mentionned, we are not dealing with high RPS but I/O bounds ops which Bun wouldn't solve.

[Siumauricio]

Unfortunately, I can't trust Bun at this time, especially as yall mentioned, dokploy relies heavily on child processes and system-related things like commands.

I tried using Bun at the beginning of dokploy's development, but this bug I encountered made me realize I couldn't fully trust it at that time even I raise a issue here oven-sh/bun#8849

[Splicho]

Is there a way to deploy bun apps tho?

[jablonski]

Is there a way to deploy bun apps tho?

Best (and most resource friendly) option is to provide your own Dockerfile. I'm using this approach without no problems at all.

If you don't want to use a Dockerfile: Nixpacks comes with (experimental) Bun support, not sure for Railpacks or Heroku Buildpacks.

Please note: this issue is about changing Node.js with Bun for running Dokploy. This isn't related in any way with running applications within Dokploy on top of Bun. If you have further questions, please start a discussion.

[Splicho]

Is there a way to deploy bun apps tho?

Best (and most resource friendly) option is to provide your own Dockerfile. I'm using this approach without no problems at all.

If you don't want to use a Dockerfile: Nixpacks comes with (experimental) Bun support, not sure for Railpacks or Heroku Buildpacks.

Please note: this issue is about changing Node.js with Bun for running Dokploy. This isn't related in any way with running applications within Dokploy on top of Bun. If you have further questions, please start a discussion.

Thank you for this information!

[gvkhna]

Although minor a quick optimization you could make is to launch the process directly in the Dockerfile.

pnpm start just launches node, which launches node again, so you have two node instances running:

From btop:

2516 node             node -r dotenv/config dist/server.mjs     17 root        383M
2061 node             node /usr/local/bin/pnpm start            11 root         60M

[tonytkachenko]

Interesting research about Bun productivity by @mcollina
https://blog.platformatic.dev/bun-is-fast-until-latency-matters-for-nextjs-workloads

[gvkhna]

I moved off of bun recently, a long standing set of memory leaks they've been unable to fix, high number of reports (including my experience) of bun just increasing in memory within hours until it consumes all ram and then crashes. Same exact code runs with node, stable, very low memory usage.

I think just starting the dokploy process directly is a simple change to save a bit of ram.

[SashaGoncharov19]

Interesting research about Bun productivity by @mcollina https://blog.platformatic.dev/bun-is-fast-until-latency-matters-for-nextjs-workloads

It's good to advertise your product by leveraging the success of another)

[Siumauricio]

Closing — migrating the entire runtime from Node.js to Bun is not feasible at this time given stability and compatibility concerns discussed in the comments.