DEV Community: Zak R.

Stop Juggling Process Managers: Meet pboss, the Runtime-Agnostic Manager for Bun, Deno, and Node.js

Zak R. — Tue, 06 Oct 2026 21:59:25 +0000

If you're a modern JavaScript or TypeScript developer, you've probably played a little runtime roulette.

One legacy project runs on Node.js. Your newer service uses Deno. Another project runs on Bun because you want its performance and built-in tooling.

The problem isn't choosing a runtime.

The problem is managing all of them.

Production tooling often assumes one runtime, which can leave you juggling different process managers, custom scripts, or compatibility layers just to keep your applications running.

That's the problem the latest version of ProcBoss (pboss) is designed to solve.

One Process Manager. Multiple Runtimes.

The latest ProcBoss update makes it runtime-agnostic without sacrificing native runtime APIs.

You don't need one process manager for Node.js, another solution for Deno, and something else for Bun.

You can use a single pboss installation to manage applications running on all three.

For example:

pboss --runtime=bun start --name bun_server ./bun_server.ts

pboss --runtime=deno start --name deno_server ./deno_server.ts

pboss --runtime=node start --name node_server ./node_server.ts

One process manager.

Three runtimes.

One consistent operational workflow.

And importantly, ProcBoss doesn't force those applications onto the same runtime.

Runtime-Agnostic Doesn't Mean "Use Node.js Everywhere"

There are different ways to build a multi-runtime tool.

The easy approach is to pick one runtime's APIs and build compatibility layers around everything else.

That wasn't the approach I wanted for ProcBoss.

Bun, Node.js, and Deno each provide their own native APIs for process management, filesystem access, HTTP servers, and other capabilities.

ProcBoss uses a runtime adapter architecture to preserve those differences instead of hiding them.

For process spawning, for example:

Bun       → Bun.spawn
Node.js   → node:child_process
Deno      → Deno.Command

The core process manager works with capabilities rather than directly depending on one runtime.

The runtime adapter provides the native implementation.

So when ProcBoss runs under Bun, it uses Bun's APIs.

When it runs under Node.js, it uses Node's APIs.

When it runs under Deno, it uses Deno's APIs.

There isn't a Node.js compatibility layer sitting between ProcBoss and Bun or Deno.

That's what makes the runtime-agnostic architecture useful rather than simply being a compatibility wrapper.

The Same Applies to Clustering

This is where the update gets particularly interesting.

A process manager that can start applications across different runtimes is useful.

A process manager that can scale those applications using native process capabilities across those runtimes is much more useful.

ProcBoss provides native cluster mode for Bun, Node.js, and Deno.

You can run multiple instances of an application:

pboss start server.ts --name api --instances max

Or specify the number of instances:

pboss start server.ts --name api --instances 4 --port 3000

Each instance is a supervised process managed by ProcBoss.

That means clustering isn't tied to node:cluster.

Instead, ProcBoss uses the appropriate process APIs for the runtime being managed.

The result is a consistent clustering model across runtimes.

Scale Without Changing Your Tooling

Suppose you have three applications:

Bun API
Deno API
Node.js API

They can all be managed by the same ProcBoss installation.

You can scale them independently and manage their lifecycles through the same process manager.

For a running application, you can change its instance count:

pboss scale my-api 8

And perform a graceful reload:

pboss reload my-api

This allows workers to be replaced progressively rather than simply killing everything and starting it again.

The exact behavior depends on the application's runtime and configuration, but the important part is that the process-management layer remains the same regardless of which JavaScript runtime your application uses.

It Goes Beyond `start`

Runtime support is only part of the update.

ProcBoss is designed to handle the operational problems that appear once your application is actually running.

Namespaces

Group related processes into a namespace and manage them as a unit.

For example:

api
worker
scheduler

Namespace startup is atomic. If a startup operation fails, ProcBoss can roll back the processes started by that invocation without unnecessarily affecting processes that were already running.

Dependencies

Applications often depend on other services.

An API might depend on PostgreSQL.

A worker might depend on Redis.

ProcBoss supports dependency declarations so required dependencies can be resolved before a process starts.

Dependencies can also refer to external system services rather than only ProcBoss-managed applications.

Health Checks

A process being alive doesn't necessarily mean the application is healthy.

ProcBoss supports health checks so you can monitor whether an application is actually responding, not just whether its process still exists.

Logs and Metrics

ProcBoss provides automatic log capture, rotation, retention, compression, real-time log tailing, and Prometheus metrics.

So the same tool managing the process can also provide the operational information needed to understand it.

Installation

ProcBoss provides a universal installer for Linux, macOS, and Windows.

Linux and macOS

curl -fsSL https://procboss.com/install.sh | sh

Windows

powershell -c "irm https://procboss.com/install.ps1 | iex"

The installer lets you select whether ProcBoss should run under Bun, Node.js, or Deno.

You can also explicitly choose the runtime when needed:

pboss --runtime=bun ...
pboss --runtime=node ...
pboss --runtime=deno ...

The selected runtime can be persisted locally, and you can change it later with:

pboss runtime change

The important distinction is that runtime selection is about how ProcBoss itself executes. The processes it manages can still use their appropriate runtime.

That is what makes mixed-runtime servers possible.

Why This Matters

The JavaScript ecosystem no longer revolves around a single runtime.

That's a good thing.

Bun, Node.js, and Deno each bring different ideas and capabilities to the ecosystem.

Developers should be able to choose the runtime that makes sense for a particular project without having to rebuild their production tooling around that decision.

That's the problem ProcBoss is trying to solve.

You can have:

project A → Bun
project B → Node.js
project C → Deno

and still have:

                    ProcBoss
                       │
          ┌────────────┼────────────┐
          │            │            │
         Bun          Node         Deno
          │            │            │
       native        native       native
        APIs          APIs         APIs

One process manager. Multiple runtimes. Native APIs.

And because clustering is runtime-aware as well, you don't need a separate scaling solution for each runtime.

What's Next?

ProcBoss started as a Bun process manager.

The project has now evolved into a runtime-agnostic process manager for modern JavaScript backends.

The goal isn't to make Bun, Node.js, and Deno behave identically.

It's to give them a consistent operational layer without taking away what makes each runtime different.

If you're running applications across multiple JavaScript runtimes, you can now manage them with one pboss.

Learn more

Have you been running different process-management tools for different JavaScript runtimes? I'd be interested to hear how you're handling mixed-runtime deployments.

The Era of Scary Cron Syntax Is Over: Meet pboss cron

Zak R. — Fri, 18 Sep 2026 01:37:31 +0000

You know the feeling. You need to run a backup script every day at 9:11am, so you open a terminal, type crontab -e, and stare at a blinking cursor waiting for you to conjure five asterisks and numbers in the correct ancient order.

11 9 * * *

Is that minute-then-hour, or hour-then-minute? Did you just schedule this for 9:11am or for the 9th minute of every hour that happens to also be... you get the idea. You copy-paste it into an online cron parser to check your own work. You feel bad about it. We all feel bad about it.

Cron syntax is one of those things every backend developer has "learned" a dozen times and forgotten a dozen times, because there's zero semantic connection between what you type and what it means. */15 * * * * doesn't look like "every 15 minutes" — it looks like line noise that happens to work.

pboss — the Bun-powered process manager — ships a cron system that fixes this without throwing away the power of raw cron when you actually need it.

The problem with `crontab -e`

Standard cron has a few real, practical downsides beyond "the syntax is opaque":

No persistence layer of its own. It's a system-level daemon, separate from whatever's managing your app processes.
No visibility. Want to know when a job last ran, whether it succeeded, or when it's running next? Better go dig through /var/log or set up your own logging by hand.
No easy one-shot scheduling. Need something to run once, next Tuesday at 11pm, and never again? You're writing a workaround, not using cron the way it was designed.
Machine downtime silently eats jobs, and figuring out what got skipped is a manual, aggravating exercise.

If you're already running pboss to manage your app processes, none of this needs to be a separate problem you solve separately.

Enter human-readable schedules

Here's the same 9:11am backup job in pboss:

pboss cron run everyday@9:11 "bun /srv/backup.ts"

Read that out loud. It says exactly what it does. No mental math, no lookup table, no "wait, is Sunday 0 or 7 in this implementation."

A few more, so you get the shape of the grammar:

# Every Sunday at 10:10am, named explicitly
pboss cron run every-sunday@10:10 "sh /srv/cleanup.sh" --name cleanup

# One-shot: fires once, at a specific date and time, then it's done
pboss cron run on-date@24-10-2026-23:10 "node migrate.js"

The grammar covers the cases you actually hit in real projects:

You want...	You write...
Every day at midnight	`everyday`
Every day at a specific time	`everyday@9:11`
Every N seconds	`every-15-seconds`
Every hour, or every hour at :30	`everyhour` / `everyhour@30`
Every week on a given weekday	`every-sunday@10:10`, `everyMonday@10:10`, `onSunday@23:10`
Every month, or a specific day of month	`everymonth` / `every-15th@10:10`
Every N hours or N days	`every-6-hours` / `every-2-days@8`
Once, later today or tomorrow	`today@23:10` / `tomorrow@8:00`
Once, on a specific calendar date	`on-date@24-10-2026-23:10`

A couple of details that show this was designed by someone who's actually been burned by cron before:

Hour 24 rolls to the next day. everyday@24:30 means 00:30 tomorrow, so you can express "half an hour after midnight" without the off-by-one anxiety.
Keywords are forgiving. on-date@, onDate@, and on_date@ are all the same thing — hyphens, underscores, and camelCase are interchangeable, so you don't have to remember one exact casing convention.
Dates are calendar-validated. Try to schedule on-date@31-02-2026 and you get a clear rejection instead of a job that silently never fires.
A past today@… time gets rejected with a suggestion, not silently scheduled into a black hole.
Missed jobs are skipped, not queued up. If the daemon or machine was down, a recurring job just reschedules to its next real future occurrence — same behavior you'd expect from classic cron, so nothing runs in a confusing backlog burst when the box comes back up.

The escape hatch: raw cron still works

This is the part that matters most, honestly. Nobody wants a "friendly" tool that boxes you in the moment your schedule gets weird. So pboss doesn't replace cron expressions — it accepts them:

pboss cron run "*/5 * * * *" "curl -s https://example.com/ping"

You can even go beyond standard 5-field cron with a 6-field expression, where the first field is seconds:

pboss cron run "*/10 * * * * *" "node heartbeat.js"

So the mental model is: reach for the friendly syntax by default, and drop into raw cron only for the genuinely gnarly schedules where a plain-English phrase can't capture what you need.

Managing jobs like they're first-class citizens

Because cron jobs live in the daemon itself (persisted to ~/.pboss/cron.json, surviving reboots), you get the same kind of visibility you'd expect for a managed process:

pboss cron list

┌────┬─────────┬─────────────┬──────────────────┬───────────────────────────┬──────┬──────┬──────────┐
│ id │ name    │ schedule    │ command          │ next run                  │ runs │ last │ status   │
├────┼─────────┼─────────────┼──────────────────┼───────────────────────────┼──────┼──────┼──────────┤
│  1 │ backup  │ everyday@9  │ bun backup.ts    │ 2026-09-07 09:00 Mon      │   14 │ ✓    │ ● online │
│  2 │ cleanup │ every-sunday│ sh cleanup.sh    │ 2026-09-13 00:00 Sun      │    3 │ ✓    │ ● online │
└────┴─────────┴─────────────┴──────────────────┴───────────────────────────┴──────┴──────┴──────────┘

Peek at upcoming runs without waiting around:

pboss cron next backup --count 5

Force a run right now, without touching the schedule:

pboss cron trigger backup

And clean up when a job's done:

pboss cron remove backup

Every run gets logged automatically to ~/.pboss/logs/cron/<name>.log, with a header (job name, schedule, working directory), the command's full combined output, and a footer with exit code and duration. That's debugging information you'd otherwise have to wire up yourself.

Declaring crons alongside your apps

If you're already using an ecosystem file to manage your processes, cron jobs slot right in next to them:

export default {
  crons: [
    {
      name: "backup",
      schedule: "everyday@2:00",
      command: "bun /srv/backup.ts",
    },
    {
      name: "report",
      schedule: "every-15th@10:10",
      command: "sh /srv/report.sh",
    },
    {
      // paused until you're ready
      name: "maintenance",
      schedule: "every-sunday@5:00",
      command: "sh /srv/maintenance.sh",
      enabled: false,
    },
  ],
  apps: [
    /* … */
  ],
};

Re-running the ecosystem file updates schedules in place — jobs are matched by name, so you can tweak a schedule and redeploy without duplicating jobs.

Or drive it all from code

import { pboss } from "pboss";

const job = await pboss.cronAdd("everyday@9:11", "bun backup.ts", { name: "backup" });

for (const j of await pboss.cronJobs()) {
  console.log(`${j.name} — ${j.description} (runs: ${j.runCount})`);
}

await pboss.cronTrigger("backup");   // run now
await pboss.cronRemove("backup");    // remove

Under the hood

Jobs execute through the system shell (/bin/sh -c on Unix, cmd /c on Windows), so pipes and redirects behave exactly like you'd expect:

pboss cron run everyday@3 "bun report.ts | mail -s 'daily report' ops@example.com"

And the scheduler itself isn't naively polling every minute and hoping — it sleeps until the next actual scheduled run with a periodic watchdog rescan, so timing stays accurate to the second even across clock adjustments.

The takeaway

Cron syntax isn't going anywhere — it's load-bearing infrastructure for the entire internet, and pboss doesn't pretend otherwise; raw expressions are still a first-class option. But for the 90% of scheduling you actually do — "run this every day," "run this every Sunday morning," "run this once, next Tuesday" — there's no reason to keep translating your intent into five cryptic fields by hand.

pboss cron run everyday@9:11 "bun /srv/backup.ts"

That's it. That's the whole horror story, and it has a happy ending.

Want to try it: check the cron docs.

Stellar AppKit: Building a Complete Application Layer for Stellar

Zak R. — Thu, 27 Aug 2026 08:47:28 +0000

Building a Stellar application shouldn't require developers to assemble a dozen different pieces before they can get to the product itself.

Wallet connectivity is only the beginning.

A production-grade Stellar application needs to handle wallet integration, responsive wallet UX, authentication, session management, Soroban transactions, transaction simulation, error handling, localization, and increasingly, compliance and user onboarding.

That is the problem we're trying to solve with Stellar AppKit.

Stellar AppKit is an application SDK designed to provide a unified layer between your application, your users, wallets, and the Stellar network.

The easiest way to think about it is:

Wallet connectivity gets a user into your application. AppKit is focused on everything that happens around that connection.

What is Stellar AppKit?

Stellar AppKit started as a wallet connectivity library, but the project has evolved into something broader.

The goal is to provide developers with reusable infrastructure for the application layer of Stellar:

Your Application
       │
       ▼
┌──────────────────────┐
│    Stellar AppKit    │
├──────────────────────┤
│ Wallet Connectivity  │
│ Authentication       │
│ Session Management   │
│ Transaction UX       │
│ Soroban Infrastructure│
│ Risk Detection       │
│ Localization         │
│ Compliance           │
└──────────┬───────────┘
           │
           ▼
   Stellar Ecosystem

Instead of every application independently implementing these primitives, AppKit aims to provide them through one consistent developer experience.

Wallet connectivity is only the starting point

There are already good wallet connectivity solutions in the Stellar ecosystem.

Stellar Wallets Kit, for example, solves an important problem: connecting applications to multiple Stellar wallets through a common interface.

We don't see that problem as the entire application stack.

A developer building a real application eventually has to answer questions like:

How should the wallet selector behave on mobile?
How do I support multiple frontend frameworks?
How do I localize the wallet experience?
How do I authenticate a user with their wallet?
How do I maintain their session?
How do I validate that authentication on the server?
How do I simulate a Soroban transaction before signing?
How do I show the user what they're actually signing?
How do I detect potentially dangerous transactions?
How do I onboard users who don't already have a wallet?
How do I handle compliance requirements?

AppKit is intended to address that larger set of problems.

A better wallet UX

Wallet connectivity APIs are useful, but the user experience surrounding a wallet connection matters just as much.

A desktop application and a mobile application shouldn't necessarily present wallet selection in the same way.

AppKit supports different UI presentation patterns, including:

Desktop modal
Mobile bottom sheet
Inline and UI-agnostic flows

This allows applications to use AppKit's ready-made experience or build their own interface around the underlying SDK.

The objective isn't to force a specific design.

It is to give developers a good default experience while keeping the underlying functionality flexible.

25 languages out of the box

Stellar is a global ecosystem, so localization shouldn't become another project developers have to maintain themselves.

AppKit currently supports 25 languages, including Chinese and other major languages.

That means wallet-related interfaces, authentication flows, and other AppKit components can be presented to users in their preferred language without every application having to implement the translation infrastructure independently.

Localization is treated as part of the application experience rather than an afterthought.

Multi-framework support

Another important design decision is keeping AppKit independent from a single frontend framework.

The core SDK is framework-agnostic, while UI integrations are available for:

React
Vue
Svelte

We're also working toward support for:

React Native
LynxJS
Flutter

The objective is to make AppKit useful across both web and mobile applications while maintaining the same underlying concepts and developer experience.

A developer shouldn't have to completely rethink wallet and authentication infrastructure just because their frontend stack changed.

Transaction UX: don't make users sign blind XDR

One of the areas we're particularly interested in is transaction understanding.

Traditionally, an application builds a transaction, produces XDR, and asks a wallet to sign it.

From the user's perspective, that can be extremely opaque.

The user may be asked to approve a transaction without having a clear understanding of:

Which operations are being executed
Which assets are moving
How balances will change
What fees are involved
Which contracts are being called
Whether there are potential risks

AppKit is designed to put an interpretation layer around transactions.

The vision is:

Transaction
     │
     ▼
Decode
     │
     ▼
Simulate
     │
     ▼
Explain
     │
     ▼
Assess Risk
     │
     ▼
User Approval

This includes capabilities around transaction previews, operation decoding, simulation, balance and fee information, contract information, and risk detection.

The goal is simple:

Users should have a much better understanding of what they are signing.

Soroban application infrastructure

Soroban introduces another layer of complexity.

A typical transaction flow isn't simply:

Create → Sign → Submit

Applications often need to:

Build
  ↓
Simulate
  ↓
Prepare
  ↓
Sign
  ↓
Submit
  ↓
Track

AppKit provides abstractions around this lifecycle so developers can work with higher-level APIs instead of rebuilding the same workflow in every project.

We're also working on capabilities such as:

Typed contract clients
Transaction helpers
RPC failover
Simulation-aware execution

The goal is to make interacting with Soroban feel more like using an application SDK and less like manually orchestrating every transaction step.

Authentication shouldn't stop at "Connect Wallet"

A wallet connection does not necessarily mean the user is authenticated in your application.

Modern applications usually need a proper authentication lifecycle.

AppKit is building Stellar authentication and session management inspired by Sign In with Ethereum (SIWE).

The system is designed around concepts such as:

Connect Wallet
      ↓
Request Nonce
      ↓
Sign Authentication Message
      ↓
Server Validation
      ↓
Create Session
      ↓
Authenticated Application

This includes:

Nonce-based authentication
Signed authentication messages
Session creation
Session persistence
Re-authentication
Sign-out
Server-side signature and session validation

The goal is to make a Stellar wallet usable as an application identity rather than treating wallet connection as the authentication mechanism itself.

Walletless onboarding

One of the bigger areas on our roadmap is walletless connectivity.

Crypto onboarding can be a significant barrier for users who have never interacted with a wallet before.

We're working toward allowing applications to onboard users through more familiar authentication methods.

Social login

Applications will be able to offer familiar social authentication flows so users can get started without first installing and configuring a traditional crypto wallet.

Passkeys

We're also working toward passkey-based authentication, allowing users to authenticate using device-native credentials and biometrics.

The broader goal is to make Stellar applications accessible to users who don't already identify themselves as "crypto users."

Instead of:

Install wallet
↓
Create account
↓
Find recovery phrase
↓
Connect wallet
↓
Start application

the experience can move closer to:

Authenticate
↓
Start using the application

while still allowing applications to interact with Stellar underneath.

Compliance and KYC

Another area we're exploring is making compliance infrastructure available directly at the application layer.

For many Stellar applications, particularly those involving regulated assets, real-world assets, financial services, or restricted jurisdictions, compliance can't simply be an external concern.

Developers may need to know whether a user:

Has completed KYC
Is eligible to use a particular application
Is from an allowed jurisdiction
Meets an age requirement
Satisfies another compliance policy

Today, developers often have to assemble separate identity and compliance systems to handle these requirements.

We're working toward allowing developers to request and manage KYC directly through AppKit.

A zero-knowledge compliance layer

The longer-term vision is to combine compliance verification with zero-knowledge technology.

Instead of putting sensitive personal information on-chain, applications could verify specific properties about a user.

For example:

KYC completed      → ✓
Allowed jurisdiction → ✓
Age requirement    → ✓
Restricted status   → ✗

without exposing the underlying personal information directly on-chain.

The objective is to make compliance:

Verifiable + Privacy-preserving + Reusable

This is still an area we're actively developing, but we believe it could become increasingly important as Stellar applications move into regulated and real-world use cases.

Why not just use a wallet SDK?

This is probably the most important distinction.

If your application only needs to connect to a Stellar wallet, a wallet-focused SDK may be exactly what you need.

AppKit is intended for applications that need more.

The difference can be summarized like this:

Wallet Connectivity	Application Layer
Connect wallet	Connect wallet
Sign transaction	Sign transaction
Wallet selection	Wallet UX
Wallet abstraction	Authentication
	Session management
	Server-side validation
	Transaction preview
	Simulation
	Risk detection
	Soroban lifecycle
	Localization
	Cross-framework UI
	Walletless onboarding
	Compliance infrastructure

We don't think developers need yet another abstraction simply for the sake of having one.

The goal is to reduce the amount of application infrastructure they have to build repeatedly.

The bigger vision

The long-term vision for AppKit is a single application layer that helps developers move through the entire user and transaction lifecycle:

                    ┌───────────────┐
                    │     User      │
                    └───────┬───────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │   Authentication │
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │     Session      │
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │ Wallet / Identity│
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │    Transaction   │
                  │ Preview / Risk   │
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │      Soroban     │
                  │    Execution     │
                  └────────┬─────────┘
                           │
                           ▼
                  ┌──────────────────┐
                  │     Stellar      │
                  └──────────────────┘

And eventually, developers should be able to choose between traditional wallets, smart wallets, social authentication, passkeys, and compliant identity flows without having to completely rewrite their application.

What's next?

We're continuing to build AppKit around the needs of Stellar developers.

Some of the areas we're working on include:

Walletless authentication

Social login
Passkeys

Cross-platform

React Native
LynxJS
Flutter

Compliance

Integrated KYC flows
Zero-knowledge-based compliance verification

Application infrastructure

More transaction intelligence
More Soroban abstractions
More wallet integrations
Improved developer tooling

The goal isn't to build the biggest SDK possible.

It's to make building a Stellar application significantly easier.

Conclusion

Stellar already has strong infrastructure for wallets, assets, payments, and smart contracts.

What we're building with Stellar AppKit is the layer around those primitives.

A developer shouldn't have to independently solve wallet UX, authentication, session management, transaction interpretation, Soroban execution, localization, and eventually compliance every time they start a new Stellar application.

The vision is straightforward:

Connect → Authenticate → Understand → Sign → Execute → Verify

That's what we're building with Stellar AppKit.

The project is open source, and we're actively looking for feedback from developers building on Stellar.

GitHub: https://github.com/SagantaHQ/stellar-appkit

Why I Stopped Using PM2 and Built My Own Bun Process Manager

Zak R. — Thu, 12 Feb 2026 15:11:08 +0000

I loved PM2. Then I switched to Bun.

Let me tell you a quick story. Six months ago, I migrated a handful of microservices from Node to Bun. The speed improvements were everything the benchmarks promised. Cold starts dropped dramatically. Memory usage shrank. I was thrilled.

Then I noticed something. My process manager, PM2, the tool I'd relied on for years, was now the slowest part of my stack. It was the thing consuming the most memory in some cases. The irony of running a Node-based supervisor over hyper-optimized Bun processes started to eat at me.

So I did what any reasonable developer does. I spent my weekends building a replacement.

The Breaking Point

The final straw wasn't one big thing. It was a cascade of small frustrations. PM2 would occasionally misreport memory usage for Bun processes. The TypeScript integration required extra flags and workarounds.

I had to maintain a separate ecosystem.json that felt increasingly disconnected from the rest of my Bun-native tooling. Every time I ran pm2 start, there was a visible delay as the Node-based daemon spun up, only to then launch a Bun process.

I started keeping a list of these friction points. After a few weeks, the list was long enough to justify a project.

What I Built

ProcBoss (pboss) is a process manager that does one thing: manage long-running Bun processes without any Node dependency.

No daemon running on a separate runtime. No compatibility layers. Just Bun managing Bun.

The CLI is deliberately familiar:

bun i -g pboss pboss start server.ts --name api pboss restart api pboss logs api --lines 100 pboss list

Under the hood, everything uses Bun's native APIs. Subprocess spawning uses Bun.spawn. File operations use Bun.write and Bun.file.

The internal state management uses Bun's built-in SQLite. No fs polyfills. No child_process from Node. Pure Bun.

The Results

After migrating my services from PM2 to ProcBoss (pboss), here's what I noticed.
The process manager itself starts almost instantly.

There's no daemon boot delay. The memory overhead of the manager dropped significantly because it's not running a full Node runtime alongside Bun.

TypeScript files just work — no flags, no config, no transpilation. And the whole thing feels coherent in a way that's hard to describe. My entire stack is one runtime now, top to bottom.

Should You Switch?

If you're running Node services, PM2 is still excellent. Seriously. It's mature, battle-tested, and feature-rich.

But if you've committed to Bun, consider whether your toolchain has actually caught up with that decision. Your runtime is Bun. Your package manager is Bun. Your test runner is Bun. Why is your process manager still Node?

That's the question that led me to build ProcBoss (pboss). Maybe it's the question you've been ignoring too.

Links
Repository: https://github.com/procboss/pboss

Package: https://www.npmjs.com/package/pboss

Deploying Solana Anchor Programs Easily with Rocket Anchor

Zak R. — Mon, 10 Nov 2025 23:50:06 +0000

If you're a developer working with Anchor on Solana, you know the drill. You build your powerful program, and then... you're stuck writing a tangled mess of ad-hoc scripts for deployment, upgrades, and account initialization. It's time-consuming, error-prone, and just plain frustrating.

What if you could have a smooth, repeatable, Hardhat-style workflow?

Meet Rocket Anchor, a new open-source tool designed to save you from deployment headaches and streamline your entire process. This guide will walk you through exactly what it is and how to get started.

What is Rocket Anchor?

Rocket Anchor is a CLI and programmatic tool that brings the developer-friendly experience of tools like Hardhat to the Anchor ecosystem.

Its main goal is to solve the "last mile" problem of Anchor development:

It replaces manual scripts with a clean, config-based CLI workflow.
It introduces "seeding," a powerful concept for initializing accounts, PDAs, and program state right after deployment.
It's built for teams, making it easy to manage deployments across different networks (devnet, mainnet) without changing your code.

Key Features

Hardhat-Inspired CLI: Get a familiar workflow with commands like init, deploy, and seed.
Powerful Seeding: Run scripts after deployment to initialize program state, create PDAs, or set up initial data. This is a massive time-saver.
Network Management: Easily configure different networks (like devnet, testnet, mainnet, custom-network) in a single config file, complete with RPC endpoints and keypair paths.
Programmatic API: Need to integrate Rocket Anchor into your existing TypeScript toolchain? You can import and use it directly.

Installation

You can install Rocket Anchor globally to use it as a CLI tool across all your projects, or locally as a devDependency in a specific project.

Global Install:

npm install -g rocket-anchor

Local Install:

npm install --save-dev rocket-anchor

Getting Started: Your First Deployment

Let's walk through the entire workflow from zero to a seeded deployment.

Step 1: Initialize Rocket Anchor

In the root of your Anchor project, run the init command:

npx ra init

This will create a new file named ra.config.ts in your project's root. This is where you'll define all your networks and deployment configurations.

Step 2: Configure Your Networks

Open the newly created ra.config.ts. This is where you'll tell Rocket Anchor how to connect to different Solana clusters.

A typical configuration might look something like this:

// ra.config.ts
import { RocketAnchorConfig } from 'rocket-anchor';

const config: RocketAnchorConfig = {
  networks: {
    // Local validator
    localnet: {
      url: "[http://127.0.0.1:8899](http://127.0.0.1:8899)",
      keypair: "/path/to/your/localnet/keypair.json",
    },
    // Devnet
    devnet: {
      url: "[https://api.devnet.solana.com](https://api.devnet.solana.com)",
      keypair: "/path/to/your/devnet/keypair.json",
    },
    // Mainnet
    mainnet: {
      url: "[https://api.mainnet-beta.solana.com](https://api.mainnet-beta.solana.com)",
      keypair: "/path/to/your/mainnet/keypair.json",
    }
  },
};

export default config;

Step 3: (Optional but Recommended) Create Seed Scripts

This is where the magic happens. "Seeding" is the process of initializing your program's state right after deployment.

Create a seeds/ directory and an index.ts file inside it (seeds/index.ts). Here, you'll define a SeedConfig array.

// seeds/index.ts

import { SeedConfig } from 'rocket-anchor';

export const seeds: SeedConfig[] = [
  {
    program: 'counter', // a name for your program
    initialize: {
      function: 'initialize',
      accounts: {
        counter: 'pda:counter',
        authority: 'signer',
        systemProgram: 'systemProgram',
      },
      args: [0], // initial_count
    },
    seeds: [
      {
        function: 'increment',
        accounts: {
          counter: 'pda:counter',
          authority: 'signer',
        },
        args: [],
        repeat: 5, // Run 5 times
      },
    ],
  },
];

export default seeds;

Step 4: Deploy and Seed!

You're all set. Now, to deploy your program to devnet and run the seed scripts immediately after, you just run one command:

npx ra deploy --network devnet --seed

Rocket Anchor will handle:

Connecting to the correct network (devnet).
Using the correct keypair.
Deploying your Anchor program.
Once deployed, it will run the seed scripts you defined for that program.

You're live! No more manual solana program deploy commands or separate initialize.ts scripts to run.

Conclusion

Rocket Anchor fills a much-needed gap in the Solana development workflow. By adopting a config-based and scriptable approach to deployments and seeding, it saves time, reduces errors, and lets you focus on what matters: building your program's logic.

Always remember to test thoroughly on devnet before deploying to mainnet. Happy building!

Introducing Truffle Solidity Data Seeder

Zak R. — Tue, 27 Apr 2021 02:17:12 +0000

The Truffle framework is an awesome toolkit for every solidity and dapp developer, we at LibertyPie make advanced use of the truffle framework.

During LibertyPie's P2P protocol development, we needed a simple way to seed initial data to different contracts similar to database seeding.

Truffle has great migration support but no seeding of data out of the box.

So we decided to build a simple CLI tool as an npm package for seeding initial data out of the box with 0 configurations.

Introducing Liberty Pie's Truffle Seeder, your easy way to seed initial data to any smart contract. Kindly help us improve it by giving us your feedback

Project: https://github.com/LibertyPie/truffle-seeder

Introducing LibertyPie’s Wallet Provider

Zak R. — Thu, 07 Jan 2021 23:58:17 +0000

As the team builds the protocol’s user interface, it is very important to research deeply into which external libraries to include. The user interface must have a rich user experience & also very light weighted.

Every DApp must find a way to connect to users’ wallet without compromising privacy and security. Fortunately, we found many matured and well-developed libraries such as web3modal (previously web3connect), web3-wallets-kit (by Akropolis), bnc-onboard (by BlockNative) & many more.

After a careful analysis of these existing solutions, we found reasons which discouraged us from using them. A major reason was the bloat in library size, other reasons included an incomplete library or having to pay for usage in the case of BloackNative bnc-onboard.

Our final resort was to build a library exactly how we wanted it, thankfully, the initial version of LibertyPie Wallet Provider is successfully published on npm (https://www.npmjs.com/package/@libertypie/wallet-provider).
LibertyPie Wallet Provider was built to provide extra advantages over other libraries, a detailed comparison has been given below.

Size (according to Bundlephobia.com)

LibertyPie Wallet Provider — 6.9kb minified +gzipped
Web3Modal — 195kb minified + gzipped
bnc-onboard — 65.1kb minified + gzipped
web3-wallets-kit — 784.4kb minified + gzipped

Best: LibertyPie Wallet Provider
Worst: web3-wallets-kit

Runtime Dependencies

LibertyPie Wallet Provider— 0
Web3Modal — 6
bnc-onboard — 20
web3-wallets-kit — 9

Best: LibertyPie Wallet Provider
Worst: bnc-onboard

Supported Wallets Providers

LibertyPie Wallet Provider — 9
Web3Modal — 11
bnc-onboard — 6
web3-wallets-kit — N/A

As seen from the data above, LibertyPie Wallet Provider has many merits compared to the other libraries.
NPM: https://www.npmjs.com/package/@libertypie/wallet-provider
Github Repo: https://github.com/LibertyPie/Wallet-Provider

DEV Community: Zak R.

Stop Juggling Process Managers: Meet pboss, the Runtime-Agnostic Manager for Bun, Deno, and Node.js

One Process Manager. Multiple Runtimes.

Runtime-Agnostic Doesn't Mean "Use Node.js Everywhere"

The Same Applies to Clustering

Scale Without Changing Your Tooling

It Goes Beyond start

Namespaces

Dependencies

Health Checks

Logs and Metrics

Installation

Linux and macOS

Windows

Why This Matters

What's Next?

Learn more

The Era of Scary Cron Syntax Is Over: Meet pboss cron

The problem with crontab -e

Enter human-readable schedules

The escape hatch: raw cron still works

Managing jobs like they're first-class citizens

Declaring crons alongside your apps

Or drive it all from code

Under the hood

The takeaway

Stellar AppKit: Building a Complete Application Layer for Stellar

What is Stellar AppKit?

Wallet connectivity is only the starting point

A better wallet UX

25 languages out of the box

Multi-framework support

Transaction UX: don't make users sign blind XDR

Soroban application infrastructure

Authentication shouldn't stop at "Connect Wallet"

Walletless onboarding

Social login

Passkeys

Compliance and KYC

A zero-knowledge compliance layer

Why not just use a wallet SDK?

The bigger vision

What's next?

Conclusion

Why I Stopped Using PM2 and Built My Own Bun Process Manager

The Breaking Point

What I Built

The Results

Should You Switch?

Deploying Solana Anchor Programs Easily with Rocket Anchor

What is Rocket Anchor?

Key Features

Installation

Getting Started: Your First Deployment

Step 1: Initialize Rocket Anchor

Step 2: Configure Your Networks

Step 3: (Optional but Recommended) Create Seed Scripts

Step 4: Deploy and Seed!

Conclusion

Introducing Truffle Solidity Data Seeder

Introducing LibertyPie’s Wallet Provider

Size (according to Bundlephobia.com)

Runtime Dependencies

Supported Wallets Providers

It Goes Beyond `start`

The problem with `crontab -e`