---
title: Handling Service Worker
---
Here you'll learn how to interact with the service worker from within your application. Service workers require a [secure context](https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts); use HTTPS in production. Browsers treat `http://localhost` as potentially trustworthy, so local Quasar development does not normally require HTTPS.

It's important to note that the Service Worker (which gets automatically generated by Workbox -- or you've configured Quasar CLI to use your custom one) runs in a separate thread. You can however interact with it from app-space from within `/src-pwa/register-sw` file.

## Interacting with Service Worker

Add the [register-service-worker](https://github.com/yyx990803/register-service-worker) package to `package.json` as a dependency if it is not already installed.

Example "/src-pwa/register-sw file":

```js
import { register } from 'register-service-worker'

register(import.meta.env.QUASAR_SERVICE_WORKER_FILE, {
  ready(registration) {
    console.log('Service worker is active.')
  },

  registered(registration) {
    console.log('Service worker has been registered.')
  },

  cached(registration) {
    console.log('Content has been cached for offline use.')
  },

  updatefound(registration) {
    console.log('New content is downloading.')
  },

  updated(registration) {
    console.log('New content is available; please refresh.')
  },

  offline() {
    console.log('No internet connection found. App is running in offline mode.')
  },

  error(error) {
    console.error('Error during service worker registration:', error)
  }
})
```

> [!NOTE]
> This file is automatically bundled into your website/app by Quasar CLI because it is considered as part of app-space `/src`.

## SSL certificate

If you access the development server through a hostname that the browser does not consider trustworthy, use HTTPS. The available options include:

- access it through `http://localhost:<port>` or `http://127.0.0.1:<port>` when developing on the same machine; browsers treat these origins as potentially trustworthy
- set quasar.config file > devServer > `https: true`
- when testing through a LAN address, custom hostname, or another device, serve your development server through an HTTPS tunnel such as [tunnelmole](https://github.com/robbie-cahill/tunnelmole-client), [localhost.run](https://localhost.run/) or [ngrok](https://ngrok.com/)

Here is a tunnelmole example. Install it first:

Example "PNPM":

```bash
pnpm add --global tunnelmole
```

Example "NPM":

```bash
npm install --global tunnelmole
```

```
$ tmole 80
http://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80
https://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80

# ...and use the HTTPS url shown in the output
```

When you set `devServer > https: true` in your quasar.config file, Quasar will instruct Vite to auto-generate a SSL certificate for you. However, if you want to create one yourself for your localhost, then check out this blog post by [Filippo](https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/). Then your `quasar.config file > devServer > https` should look like this:

Example "/quasar.config file":

```js
devServer: {
  https: {
    // Use ABSOLUTE paths or path.join(import.meta.dirname, './root/relative/path')
    // https://nodejs.org/api/https.html#https_https_createserver_options_requestlistener
    key: "/path/to/server.key",
    pfx: "/path/to/server.pfx",
    cert: "/path/to/server.crt",
    ca: "/path/to/ca.pem",
    passphrase: 'vite-dev-server' // do you need it?
  }
}
```

More info on Vite and HTTPS [here](https://vitejs.dev/config/#server-https).

## Important Hosting Configuration

It's important that you do not allow browsers to cache the Service Worker file (by default: `sw.js`). Because otherwise updates to this file or to your app might slip through the cracks for browsers that load the service-worker from cache.

This is why you must always make sure to add `"Cache-Control": "no-cache"` to the headers of `sw.js` file via your hosting service.

As an example how this is done for Google Firebase, you would add the following to the `firebase.json` configuration:

```json
{
  "hosting": {
    "headers": [
      {
        "source": "/sw.js",
        "headers": [{ "key": "Cache-Control", "value": "no-cache" }]
      }
    ]
  }
}
```