seems to be hosted on IC, but why this domain name does not need redirection


@cryptoschindler maybe Moritz can explain :slightly_smiling_face:

1 Like

I think you do this using the ICXProxy. How do you use it? Someone with more networking chops will have to explain.

An entry over would be good

it’s actually surprisingly easy and has been around for a while, i just never had the chance to try it!
thanks to @jplevyak & @ali.piccioni we have this.

  1. sign up to firebase and create a new project (you can use other services like vercel as well but then you’ll need to change the makefile). make sure you add your custom domain to the firebase hosting, in our case

  2. clone the repo and change line 13 and 14 in the makefile from

$EDITOR service-worker/src/sw/http_request.ts 


@read EDITOR; \
$$EDITOR service-worker/src/sw/http_request.ts

i had to do this so the makefile works in zsh and bash.

  1. next run make setup. when the command line prompts
update CANSTER_ID and MY_DOMAIN in agent-js/apps/sw-cert/src/sw/http_request.ts

enter the name of your favourite editor (vim for example). this opens an editor where you need to change the CANISTER_ID and MY_DOMAIN to your respective values. save and close the editor.

  1. next we are prompted to setup firebase. choose
    Hosting: Configure files for Firebase Hosting and (optionally) set up GitHub Action deploys and then Use an existing project. Now you should see and select the project you created in the first step. Keep the public directory at the default public, choose N when asked about the single-page app and automatic builds and deploys.

  2. next you need to run make build, this will build the service worker, copy it to the public directory and then deploy it with firebase.

  3. if you want to change something in the service worker just run make build to redeploy it

Now we basically have a GET request to our domain return the service worker to the client. After the service worker is installed in the clients browser, it will then communicate with the asset canister and validate the responses.

This is the same thing that happens when you access a canister through <canister_id>, just that now the “boundary node” (boundary nodes can do more than that) is under your control.

Hope that helps, enjoy your custom URLs!


thank you for sharing this! I got my domain connected, but got another error as below when I tried to access my custom domain

Failed to fetch response: TypeError: Failed to execute ‘fetch’ on ‘WorkerGlobalScope’: Illegal invocation

Any idea?

Are you using service-worker manually?
I had a similar problem and this is how I solved it. You need to upgrade service-worker code by passing fetch to HttpAgent


  • Find const agent = new HttpAgent({ host: replicaUrl.toString() });
  • And replace
      const agent = new HttpAgent({
        host: replicaUrl.toString(),
        fetch: self.fetch.bind(self),

Hope this helps


@3cL1p5e7 works perfectly!!
thank you!

1 Like

Just in case, I posted a PR
@frederikrothenberger Is it allowed to publish PR to dfinity/ic? I didn’t find any PR from community and it worries me

Hi @3cL1p5e7

Thank you for submitting the PR. Unfortunately, at the current time we do not accept external PRs for the main IC repo. But we are working on it and are planning to accept PR’s for some repos in the near future.

Regarding the actual service worker issue at hand: streaming support is definitely on our radar and we are aware that we need to support this use case in the future.

I will keep you updated regarding future developments of both accepting external contributions and changes to the service worker.

Best regards,


Thank you so much for your reply, Frederik! :bomb:

I suggest adding contribution guidelines stating as much: