Workers can be used to run code on multiple threads. Each instance of Worker is run on a separate thread, dedicated only to that worker.

Currently Deno supports only module type workers; thus it’s essential to pass the type: "module" option when creating a new worker.

Use of relative module specifiers in the main worker are only supported with --location <href> passed on the CLI. This is not recommended for portability. You can instead use the URL contructor and import.meta.url to easily create a specifier for some nearby script. Dedicated workers, however, have a location and this capability by default.

`

`

Creating a new Worker instance is similar to a dynamic import; therefore Deno requires appropriate permission for this action.

For workers using local modules; --allow-read permission is required:

main.ts

`

new Worker(new URL("./worker.ts", import.meta.url).href, { type: "module" });

`

worker.ts

`

console.log("hello world");self.close();

`

`

$ deno run --allow-read main.tshello world

`

For workers using remote modules; --allow-net permission is required:

main.ts

`

`

`

console.log("hello world");self.close();

`

`

`

By default the Deno namespace is not available in worker scope.

To enable the Deno namespace pass deno.namespace = true option when creating new worker:

main.js

`

const worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",  deno: {    namespace: true,  },});worker.postMessage({ filename: "./log.txt" });

`

worker.js

`

self.onmessage = async (e) => {  const { filename } = e.data;  const text = await Deno.readTextFile(filename);  console.log(text);  self.close();};

`

log.txt

`

hello world

`

`

`

This is an unstable Deno feature. Learn more about .

By default a worker will inherit permissions from the thread it was created in, however in order to allow users to limit the access of this worker we provide the deno.permissions option in the worker API.

• For permissions that support granular access you can pass in a list of the desired resources the worker will have access to, and for those who only have the on/off option you can pass true/false respectively.

  `

  const worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",  deno: {    namespace: true,    permissions: [      net: [        "https://deno.land/",      ],      read: [        new URL("./file_1.txt", import.meta.url),        new URL("./file_2.txt", import.meta.url),      ],      write: false,    ],  },});

  `

• Both deno.permissions and its children support the option "inherit", which implies it will borrow its parent permissions.

  `

  // This worker will inherit its parent permissionsconst worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",  deno: {    namespace: true,    permissions: "inherit",  },});

  `

  `

  // This worker will inherit only the net permissions of its parentconst worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",  deno: {    namespace: true,    permissions: {      env: false,      hrtime: false,      net: "inherit",      plugin: false,      read: false,      run: false,      write: false,    },  },});

  `

• Not specifying the deno.permissions option or one of its children will cause the worker to inherit by default.

  `

  // This worker will inherit its parent permissionsconst worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",});

  `

  `

  // This worker will inherit all the permissions of its parent BUT netconst worker = new Worker(new URL("./worker.js", import.meta.url).href, {  type: "module",  deno: {    namespace: true,    permissions: {      net: false,    },  },});

  `

• You can disable the permissions of the worker all together by passing false to the deno.permissions option.

  `