what if I bundle my project as an executable, how would that work with sandboxed processors?

[arthurvanl]

Because then that file would not exist anymore

[egeominotti]

Great question — this is a real limitation right now.

The problem

SandboxedWorker works by dynamically generating a wrapper script that does await import('<your-processor-path>'). When you compile with bun build --compile, the processor .ts file gets bundled into the binary and no longer exists as a separate file on disk. The import() call fails because the path points to nothing.

The path resolution logic (in src/client/sandboxed/wrapper.ts) is:

const fullPath = processorPath.startsWith('/')
  ? processorPath
  : `${process.cwd()}/${processorPath}`;

So it always expects a real file at that path.

Current workarounds

Option 1: Ship processor files alongside the binary (recommended)

Keep your processor files as separate .ts files next to the compiled binary. Don't bundle them:

# Build the main app
bun build --compile src/main.ts --outfile dist/myapp

# Copy processor files alongside
cp src/processors/*.ts dist/processors/

Then reference them with an absolute or relative path:

const worker = new SandboxedWorker('queue', {
  processor: './processors/myProcessor.ts',  // exists on disk next to binary
});

This is the simplest approach and works reliably.

Option 2: Use the regular Worker instead

If you want a single binary with no extra files, switch to the regular Worker class which takes an inline function (no file path needed):

import { Worker } from 'bunqueue/client';

const worker = new Worker('queue', async (job) => {
  // Your processing logic directly here
  return await processJob(job.data);
}, { embedded: true, concurrency: 3 });

The trade-off: regular Worker runs in the same thread as your app (no subprocess isolation). If you need memory isolation, option 1 is better.

Option 3: Use TCP mode with a separate worker process

Run bunqueue as a server, and have a separate (non-compiled) worker process:

# Terminal 1: your compiled app (pushes jobs)
./dist/myapp

# Terminal 2: worker process (separate, with source files)
bun src/worker.ts

This gives you full isolation without needing the processor file in the binary.

Future improvement

I'll look into supporting an inline processor function for SandboxedWorker (similar to how regular Worker works but spawned in a subprocess). This would let you do:

// Hypothetical future API
const worker = new SandboxedWorker('queue', {
  processor: async (job) => { /* inline */ },  // no file needed
  maxMemory: 512,
});

For now, option 1 (ship processor files alongside the binary) is the recommended path. Let me know if you need help setting it up!

[arthurvanl]

Seems pretty neat if you can have an inline processor.

About the TCP/servermode option. So I would need to have a bunqueue app running, my compiled app & the worker.
So I would have 3 containers running right?

But I am starting with a new project that will have a lot of jobs per 30 minutes. So I think I should use the TCP mode.

For now Ill keep my code uncompiled for now as it allows to change things much easier when necessary.