---
title: "Deno"
description: "Consume npm:logbun with path-scoped filesystem permissions and instance locking."
---

> Documentation Index
> Fetch the complete documentation index at: https://logbun-docs.abshahin.workers.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Deno

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

```ts
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

```sh
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](/guides/production#filesystem-security-model).

Source: https://logbun-docs.abshahin.workers.dev/guides/deno/index.mdx