Deno gives JavaScript and TypeScript developers a secure runtime, built-in TypeScript support, and a permission system that puts you in control of what your application can access.
But running a production application involves more than choosing a runtime. What happens when a process crashes? How do you use multiple CPU cores? Can you restrict filesystem and network access without making deployment complicated? And how do you know when a service is unhealthy before your users start reporting errors?
That is where a process manager becomes useful.
pboss is an open-source, runtime-agnostic process manager for Bun, Node.js, and Deno. It adds process supervision, clustering, health checks, resource monitoring, and lifecycle management while letting your application continue to run on Deno.
In this article, we will explore practical ways to use pboss to improve the performance, resilience, and security of self-hosted Deno applications.
1. Start with Deno's security model
Before introducing a process manager, it is worth understanding what Deno already provides.
Unlike runtimes that grant applications broad system access by default, Deno denies most sensitive I/O operations unless the required permissions are explicitly granted. These include filesystem access, network connections, environment variables, and subprocess execution.
For example, a server might need permission to listen for HTTP requests and read a configuration file:
deno run --allow-net=127.0.0.1:8000 --allow-read=./config server.ts
This is better than automatically granting unrestricted access with:
deno run -A server.ts
The -A flag grants all permissions, effectively removing Deno's permission sandbox.
The principle is simple: give an application only the permissions it needs to perform its job.
For more details, see the Deno security and permissions documentation.
2. Manage Deno permissions through pboss
Remembering and maintaining permission flags across multiple production applications can become tedious. pboss lets you define Deno permissions when starting a process.
For example, to run an HTTP server with network access and read access limited to a configuration directory:
pboss start server.ts --name api --interpreter deno --permissions allow-net=127.0.0.1:8000,allow-read=./config
You can also run a Deno process without granting additional permissions:
pboss start worker.ts --name restricted-worker --interpreter deno --perms none
This is useful for workloads that do not need network access or filesystem access beyond what Deno allows by default.
You can configure permissions in an ecosystem file as well:
module.exports = {
apps: [
{
name: "deno-api",
script: "./server.ts",
interpreter: "deno",
permissions: [
"allow-net=127.0.0.1:8000",
"allow-read=./config",
"deny-write"
]
}
]
};
The example illustrates a deliberately restricted API process. Adjust the permissions to match your application's actual requirements.
For example, a database-backed API may need outbound network access to a database host, and a file-upload service may need write access to a specific upload directory. Those permissions should be added explicitly rather than granting unrestricted access.
pboss supports Deno-specific permission declarations, including scoped allow and deny rules. If you explicitly configure permissions, pboss passes the appropriate flags to Deno; if you leave them unspecified, Deno's default deny-by-default behavior remains in effect.
Important: A process manager does not make an application secure by itself. Review the permissions your application and dependencies need, protect secrets, and avoid granting broad permissions simply to make errors disappear.
3. Use clustering to take advantage of multiple CPU cores
A single Deno server process can handle concurrent asynchronous I/O very well. However, CPU-intensive work can still limit throughput, and a single process cannot automatically distribute its JavaScript execution across all CPU cores.
For workloads that benefit from multiple independent processes, pboss supports clustering.
Start a server with four instances:
pboss start server.ts --name api --instances 4 --port 8000
Instead of supervising just one process, pboss manages multiple application instances. This can help distribute incoming requests across workers and improve throughput when your workload benefits from parallel processing.
Independent workers can also provide better resilience. If one worker exits unexpectedly, the process manager can detect the failure and attempt to replace it rather than leaving that worker permanently unavailable.
Keep in mind that more instances are not always better. Each worker consumes memory and may create its own database connections, caches, and background tasks. Choose an instance count based on available CPU and memory, database connection limits, and realistic load tests.
For a lightweight I/O-bound application, one process might already be sufficient. For CPU-heavy endpoints, larger workloads, or services that need multiple independent workers, clustering is worth testing.
4. Recover automatically from crashes
A production process can fail for many reasons:
An uncaught exception terminates the process.
A memory leak eventually exhausts available memory.
A dependency becomes unavailable and exposes an unhandled failure path.
A deployment introduces a regression.
An administrator or operating system terminates a process.
Without supervision, an unexpected exit can leave a service offline until someone intervenes.
pboss monitors managed processes and can restart processes that exit unexpectedly. It also provides lifecycle management, health checks, and restart policies to help keep services running.
For example:
pboss start server.ts --name api
pboss list
The first command starts a managed process; the second lists managed processes and their status, including operational information such as resource usage and restart counts.
For clustered workloads, pboss can supervise individual workers instead of requiring you to manually relaunch the entire application whenever a worker dies.
Automatic restarts are not a substitute for fixing application bugs. A process that crashes repeatedly may remain unhealthy despite being restarted. Use restart monitoring and health checks to identify recurring failures, and investigate the underlying cause rather than treating every restart as a successful recovery.
5. Measure performance instead of guessing
There are several ways to improve the operational performance of a Deno application:
Reduce unnecessary restarts. Faster startup and recovery reduce the time a service spends unavailable.
Scale only when needed. Add workers when testing shows that a single process is a bottleneck.
Watch memory and CPU usage. Resource monitoring helps identify excessive memory consumption and CPU saturation.
Keep logs manageable. Log capture, rotation, retention, and compression help prevent logs from consuming excessive disk space.
Benchmark realistic traffic. Test the endpoints, payload sizes, concurrency levels, and dependency patterns that resemble production.
pboss includes process monitoring and supports Prometheus metrics, making it possible to observe resource consumption and integrate process-level metrics into a wider monitoring setup.
What about actual benchmarks?
The pboss repository publishes benchmark results comparing Deno workloads managed by pboss and pup.
In the published test environment, the two managers had similar throughput in fork mode, where each ran a single application process. In the tested two-worker cluster scenario, pboss recorded substantially higher throughput and lower average latency.
There is an important qualification: the two managers use different clustering architectures. pboss uses independent workers sharing a port through SO_REUSEPORT, while pup uses a built-in load balancer in front of backend workers. These results describe a particular test setup, not a guarantee that every application will see the same improvement.
The right approach is to reproduce the benchmark with your own application, runtime version, hardware, and workload before deciding how many workers to run.
6. Keep configuration compatible with your existing workflow
If you already use PM2-style ecosystem configuration, switching process managers does not necessarily mean rewriting your entire process configuration.
pboss supports ecosystem configuration files and can automatically discover common filenames, including ecosystem.config.js and ecosystem.config.ts.
For example, an existing ecosystem file can describe the application to run:
module.exports = {
apps: [
{
name: "api",
script: "./server.ts",
interpreter: "deno",
instances: 2
}
]
};
You can then start the configuration with:
pboss start
pboss supports PM2-compatible ecosystem configuration, but compatibility does not mean every PM2-specific option or behavior is identical. Check the documentation when relying on advanced configuration features.
The benefit is a familiar configuration workflow combined with Deno-specific permission handling and process supervision.
7. Add visibility with ProcBoss Cloud (optional)
A process manager helps keep processes running, but you still need to know what is happening across your servers.
ProcBoss Cloud is an optional service that extends pboss with centralized operational features.
Depending on your setup, it can help you:
Manage multiple servers from one dashboard: Monitor your fleet without logging into every machine individually.
Receive critical error alerts: Get notified about important errors and crashes rather than constantly reading verbose logs.
Manage processes through Telegram or Discord: Perform supported process-management operations through connected chat integrations.
Deploy from GitHub: Automatically redeploy when your repository is updated, with rollback to the previous working deployment if the new version fails to start.
Publish status pages: Give users visibility into selected services through a public status page at [organization_name].status.zone.
This helps connect process-level supervision with the day-to-day work of operating production services.
The open-source pboss CLI remains usable independently. ProcBoss Cloud is optional; you do not need a Cloud subscription to use the process manager.
8. Install pboss and try it with Deno
If you want to run pboss using Deno, you can install it through the universal installer:
curl -fsSL https://procboss.com/install.sh | sh -s -- --runtime=deno
Alternatively, install the Deno entry point directly:
deno install -g -A --min-dep-age=0 --name pboss --reload --force npm/deno-entry
The installer command uses the runtime you specify. The direct Deno installation grants the permissions needed by the process manager itself; that is separate from the permissions granted to the applications it manages.
Verify the installation:
pboss --version
pboss runtime
Start a simple Deno server:
pboss start server.ts --name my-api --interpreter deno
pboss list
For detailed installation instructions and supported options, visit the pboss documentation.
Conclusion
Deno already gives developers a strong foundation for building secure JavaScript and TypeScript applications. Production reliability requires another layer of work: supervising processes, recovering from failures, scaling across workers, monitoring resources, and keeping permissions appropriately restricted.
pboss brings those operational capabilities together while running Deno applications natively.
The goal is not to make every application faster simply by adding another tool. It is to give you better control over how your application runs, how it recovers, how it scales, and how you observe it in production.
If you self-host Deno applications, give pboss a try, explore the documentation, and benchmark it against your actual workload.
Feedback, issues, and contributions are welcome.
