How are people deploying multiple sites?

General
1

I’m looking for a bit of inspiration, or maybe some pointers on the common convention. I’m planning host a second site on a VPS where Caddy is set up as as systemd service. It’s configured as a reverse proxy for a Python app and file server for static content for one website. The second site will be completely static. I want to be able to keep the sites separate from one another and develop the Caddyfiles for them as part of the sites themselves and import them in the main Caddy file.

After a bit of messing around I’ve come up with the below setup:

#===========================
# /etc/caddy/Caddyfile
import app-1/Caddyfile app-1
import app-2/Caddyfile app-2

# ==========================
# /etc/caddy/app-1/Caddyfile
www.app1.com {
    handle_path /static/* {
        root * {args[0]}/static
        file_server
    }

    reverse_proxy localhost:8000
}

#===========================
# /etc/caddy/app-2/Caddyfile
www.app2.com {
    root * {args[0]}/site
    file_server

    reverse_proxy localhost:8001
}

app-1 and app-2 are symbolic links to directories containing the code and Caddyfile for those sites.

This does work but it feels a little bit hacky. I don’t really like the import argument that’s required to tell the file server the correct location to serve from. Essentially what I’d like is a way to infer the relative path from the root Caddyfile somehow. Is there a cleaner way to do what I have here?

As mentioned, I’m all ears for any advice around conventions. If what I’m doing is just outright weird let me know! Does it even make sense to keep a Caddyfile with the site it’s for, or should development and deployment concerns be kept separate?

An option could be to package the separate apps as individual Caddy server Docker images and set up the systemd Caddy as a reverse proxy, but this sounds a bit overcomplicated and I feel like there’s a clean solution utilising a single Caddy instance staring me in the face, I just can’t identify it :stuck_out_tongue:

Apologies if this falls under a different category. It felt like more of a discussion than a traditional help request to me.

Thanks

2

This will be my similar setup:
(added extra just in case)

/aaa/bbb/Caddyfile

{
    email myaddress@email.com
    log default {
        output file /var/log/caddy.log
    }
    ...
    ...
}

https:// {
    @www header_regexp www Host ^www\.(.*)$
    redir @www https://{re.www.1} 301
}

import /aaa/bbb/site/*

/aaa/bbb/site/app1.com

app1.com {
    redir /static /static/
    handle_path /static/* {
        root * /aaa/bbb/{args[0]}/static
        file_server
    }
    reverse_proxy localhost:8000
}

/aaa/bbb/site/app2.com

app2.com {
    redir /site /site/
    handle_path /site/* {
        root * /aaa/bbb/{args[0]}/site
        file_server
    }
    reverse_proxy localhost:8001
}

each site is serve by single file which allow automation if needed.

3

I ended up doing something similar. The thing that annoyed me with my previous solution was the duplication in the import arguments (e.g., import sites/some_site some_site.). I (for better or worse) moved my site to a slightly more involved build process that greatly simplifies installation. I’ve never heard of deploying a website in this way, but it’s not exactly revolutionary:

I have a custom static site generator (don’t ask!) which produces all of the files that make up the site, including a Caddyfile with some paths merged into it. I basically replace things like {$SITE_ROOT} with whatever values are required.

I package this all up in a .deb with a postinst script that creates a symlink under /etc/caddy/available-sites to the site specific Caddyfile and instructs Caddy to reload. The .deb is a bit overkill and this probably not the intended usecase but it gives me and easy way to define where on the file system everything should go, and really trivial atomic deployments. Rolling back is as as simple as swapping the symlink back. Removing old versions can be done with dpkg as well. It’s really a very nice solution in my opinion.

I created an Ansible playbook to do the deployment automatically so the process for pushing changes is something like make install and it’s all done.

I do think this is a bit overengineered for an essentially static site, but I was having fun at the time so this is what we ended up with :slight_smile: