They won’t, because loot boxes are their main source of income.

And this is exactly why “good companies” like Valve cannot save us. Good companies will never be a substitute for good regulations.

So, basically, the trick to setting this up in Caddy is more one of not doing anything. Caddy is so much smarter than Nginx that it just figures out all this stuff for you.

So this:

# Notes Server - With WebSocket
server {
    listen 80;
    server_name notes.domain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name notes.domain.com;

    ssl_certificate /etc/letsencrypt/live/notes.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/notes.domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://localhost:5264/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

in Caddy becomes this:

auth.domain.com {
        reverse_proxy IP_ADDRESS:8264
}

Yeah. This is why I love Caddy.

In the end I only had to include a couple of the header modifiers to get everything working. So my finished file looked like this:

auth.domain.com {
        reverse_proxy IP_ADDRESS:8264 {
                header_up Host $host
                header_up X-Real-IP $remote_addr
        }
}

notes.domain.com {
        reverse_proxy IP_ADDRESS:5264
}

events.domain.com {
        reverse_proxy IP_ADDRESS:7264
}

mono.domain.com {
        reverse_proxy IP_ADDRESS:6264
        header / Cache-Control "public, no-transform"
        header / X-Cache-Status $upstream_cache_status
}

Obviously, update “domain.com” and “IP_ADDRESS” to the appropriate values. I’m actually not even 100% sure that all of that is necessary, but my setup seems to be working, including the monograph server.

One very important aside though; in your .env file, don’t do this:

AUTH_SERVER_PUBLIC_URL=https://auth.domain.com/
NOTESNOOK_APP_PUBLIC_URL=https://notes.domain.com/
MONOGRAPH_PUBLIC_URL=https://mono.domain.com/
ATTACHMENTS_SERVER_PUBLIC_URL=https://files.domain.com/

Those trailing slashes will mess everything up. Strip them off so it looks like this:

AUTH_SERVER_PUBLIC_URL=https://auth.domain.com/
NOTESNOOK_APP_PUBLIC_URL=https://notes.domain.com/
MONOGRAPH_PUBLIC_URL=https://mono.domain.com/
ATTACHMENTS_SERVER_PUBLIC_URL=https://files.domain.com/

Took me a while to work that one out.

I might still need to tweak some of this. I’m getting an occasional “Unknown network error” in the app, but all my notes are syncing, monographs publish just fine, and generally everything else seems to work, so I’m not entirely sure what the issue is that Notesnook is trying to tell me about, or if it’s even something I need to fix.

Edit: OK, the issue was that I didn’t have files.domain.com setup. Just directly proxying it solves one error, but creates another, so I’ll need to play with that part a little more. It’s probably down to Minio doing it’s own proxying on the backend (because it rewrites http requests at 9009 to https at 9090). Will update when I get it working. Anyway, for now everything except attachments seem to work.

Well, thanks to your guidance I was able to get my own server up and running. Converting the reverse proxy to Caddy was very easy, but then everything involving Caddy is stupidly easy. That also removed all the steps involving certs.

I’m going to try leaving out the subdomain for the S3 storage. Notesnook doesn’t seem to require it in the setup, whereas the other four addresses are specifically requested, and I feel like it would be better for security to not have Minio directly accessible over the web.

I also really want to try attaching their web app to this. They don’t seem to have their own docker release for it though, unless I missed something.

Hi, thank you so much for posting this. It’s a much better tutorial than the one provided by the Notesnook devs.

With that being said, I think it would be really helpful to have a bit more of a breakdown of what these individual components are doing and why. For example, what is the actual purpose of strapping a Monograph server onto this stack? Is that needed for the core Notesnook server to work, or is it optional? Does it have to be accessible over the web or could we leave that as a local access only component? Same questions for the S3 storage. Similarly, it would be good to get a better understanding of what the relationship is between the identity server and the main server. Why do both those components have to be web accessible at different subdomains?

This sort of information is especially helpful to anyone trying to adapt your process; for example, if they’re using a different reverse proxy, or if they wanted to swap in a different storage back-end.

Anyway, thanks again for all the time you put into this, it is really helpful.