Forem: Zak R.

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

BM2 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:

npm i -g bm2 bm2 start server.ts --name api bm2 restart api bm2 logs api --lines 100 bm2 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 BM2, 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 BM2. Maybe it's the question you've been ignoring too.

Links
Repository: https://github.com/bun-bm2/bm2

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

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