Anyone have a ready-made, tried and true, tested, Duplicati config for Caddy?

(J. Scott Elblein) #1

Save myself some keystrokes here, :yum:

(Matthew Fay) #2

I did this once. All I needed was a proxy to the host running Duplicati, on the default port (8200). {
  proxy / [duplicati-host]:8200

(J. Scott Elblein) #3

Hi Matt

Unfortunately that doesn’t work, try it :slight_smile: (

The main issue i think is that Duplicati still doesn’t have the usual built-in setting to add the base url that most other web apps add for reverse proxy users. Why they haven’t added it yet, I have no idea, it seems that it’s been requested several times already.

I’ve gotten ‘pretty close’ to getting it working, but only got the page itself loaded; all of it’s assets didn’t load, so you’d only see a white page with the source on it, and it’s place holder tokens, unrendered. Then I ran out of time to keep fighting with it, and had to move onto other issues needing tackling.

It looks like there’s some url rewriting necessary, and needing to exclude the ‘/duplicati’ from the path in some cases, while keeping it in others … really weird. It also seems like you might need to individually proxy each $%^#^ sub folder for the assets as well, but I never got that working. (see post)

Then again, I’m a n00b to Caddy still (only been using it for about a week), so perhaps more experienced Caddy’ers will know right away how to handle this. crossing fingers lol

(Matthew Fay) #4

So I went and reinstalled Duplicati on a VPS host to test this. I got it working with the following Caddyfile: {
  proxy / localhost:8200

The only drawback was that in later updates, Duplicati is very particular about which hostnames you’re allowed to access it from. Until you’ve configured it, it only allows localhost. This means that it can’t be proxied to by an external host until you’ve logged on locally, but you get an error:

The host header sent by the client is not allowed

Since my environment is Docker, I simply configured the Duplicati container with network_mode: service:caddy so that Caddy could reference it by localhost:8200, and you can browse to to see the result.

[edit: In retrospect, based on the wording of the setting and the error, I suspect that configuring the header_upstream Host localhost subdirective might get around this, too, but I didn’t actually test that.]

If you’re still having problems, post your Caddyfile and we’ll see if someone can figure out what might be causing them.

That said, with the way you mention the path /duplicati and the base URL setting, I’ve got a feeling you’re going to tell me you’re trying to put it in a subfolder. That’s not going to be easy at all, and you’ll notice that the config I posted originally and the one in this post both don’t use a subfolder, they give Duplicati the entire web root of a subdomain instead.

This issue pops up very frequently, and I’ve made a number of posts on the topic, the most recent being here:

The nginx config you posted by way of example would be the stopgap method 3 I mention there.

(J. Scott Elblein) #5

Aaaaaaa HAAAAA! So that’s the problem. You nailed it; I have duplicati as a subfolder of the root.

I run both duplicat and Caddy on the same local machine, and set the Caddy server to a sub domain like

Then try to set all reverse proxies through that. In most cases, the sites that run on their own server + port I can just do the usual proxy /whatever, and set the baseurl of /whatever in it’s settings, but duplicati doesn’t like that.

I guess I’ll just create another subdomain in the caddyfile just for duplicati, and maybe add that subdomain to my hosts file, or something. I’m only wanting to use duplicati locally, to backup local machines.

Side note, while researching the issue I had come across another post where someone suggested using the Filter plugin to append the baseurl to all pages, to ‘force’ it when the web app itself doesn’t already have it built-in; i cant find the original post, but doing a search just now came up with an even better one:

I wonder if this would be just as good? I guess I’ll just have to give it a try. :slight_smile:

Anyway, thanks a million for taking the time to install it and figure it out, it’s genuinely appreciated!

(Matthew Fay) #6

It’s worth a shot.

The only thing that filter won’t do is change Location headers, which means that while you can fix links in HTML, a login redirect or similar might still be “broken”.

This PR (which has been sitting for a little while, unfortunately) would give proxies the ability to regex rewrite headers as they come back from upstream, which would solve this part of the puzzle:

Combined, you could “jail” any app properly in a subfolder, abstracting all the link differences without needing a base URL.