Deno

Deno uses the npm package. There is no separate Deno build.

import { AuditLogger, ENTERPRISE_DEFAULTS, type IAdapter } from 'npm:logbun';
import { FileReliabilityAdapter } from 'npm:logbun/durability/filesystem';

declare const destination: IAdapter;

const instanceId = Deno.env.get('INSTANCE_ID') ?? 'my-app-instance-1';

const audit = new AuditLogger({
  ...ENTERPRISE_DEFAULTS,
  namespace: 'my-app',
  reliability: new FileReliabilityAdapter({
    namespace: instanceId,
    dataDir: '.logbun',
    wal: { fsync: true },
    dlq: { fsync: true },
  }),
  adapter: destination,
});

Permissions

deno run --allow-env=INSTANCE_ID --allow-read=./.logbun --allow-write=./.logbun --allow-sys=uid,gid app.ts

Grant read/write on whatever dataDir you configure (default .logbun). The path may be absent on first run. When Deno denies metadata access above that missing path, Logbun treats the denial as the runtime capability boundary and validates created in-scope paths afterwards.

--allow-sys=uid,gid covers ownership metadata used by Deno’s Node-compatible filesystem implementation.

Live exclusivity does not require --allow-run. Automatic recovery of a lock left by a crashed Deno process does: add --allow-run if this process must probe PIDs. Without it, stale locks fail closed until an operator verifies the namespace is fully stopped and removes .instance.lock and .instance.lock.recovery. Never remove them while an owner or recovery claimant may still run.

See the filesystem security model.