Multiple server types in one process?

I’ve recently started using Caddy to serve my personal website, and I love it - so much configuration just disappears :smiley: - and I’m looking into using it for DNS, and possibly other stuff too.

Do I actually need two processes for this? If I compile a caddy with both DNS and HTTP support, it would be nice to have them in a single process. Certainly not essential, though.

Looking to the future, I’d quite like to add more server types - a generic TCP proxy for SSL termination comes to mind immediately - but the attraction of that is lessened considerably if I need to run multiple processes for it :confused:

Why do you need them in one process?

I don’t need them to be (although I could construct some weird SNI shared port edge cases that would require it). It’s just a matter of how I prefer to organise things.

To me, it makes more sense to have a process per organisational unit (roughly, domain name) than a process per type of server. I could have N*M processes - one per server type, per domain - but the organisational overhead of that quickly becomes worrisome.

Then there’s the matter of configuration. I suppose in the long run, I’m looking to a bright future where I have a single Caddyfile+ that contains HTTP and DNS configuration - perhaps looking a little like: {
    http {

    dns {

    tlsproxy {

I’m also quite used to NGINX, which lets you do HTTP, IMAP and generic TCP proxying all in the same process, so this just feels natural to me.

Mostly, though, this comes about because I love having my lets-encrypt certificates managed automatically for me by caddy, but I’m not just using them for HTTP. DNS doesn’t use them, so having separate DNS and HTTP processes isn’t a big deal, but a generic TLS-terminating TCP proxy is another matter.

It would let me do away with my current system of copying the files somewhere else for IMAP and SMTP, in favour of having Caddy doing the decryption, forwarding to my mail servers as unencrypted TCP (it’s all on localhost :smiley:).

But then my configuration is split out across more files than I like, and I have to manage more processes than I like, and how well does caddy deal with sharing the certificate cache between multiple caddy processes anyway?

We’re working on functionality that will make it possible for Caddy to share the certificate storage between multiple processes. It just won’t be ready for a while yet.

I suppose with lots of careful effort, I could envision starting caddy with multiple Caddyfiles at once, each one associated with a server type.

You make a pretty good case, and the example Caddyfile you gave does look like a neat way of doing things, but it seems to me like this is a topic of opinion. I imagine it would take much rewriting just in terms of parsing the Caddyfile, as one example, and would Caddy maintain backwards compatibility with our current Caddyfile layout? Starting with multiple Caddyfiles sounds like an interesting compromise if the objective was purely to have the server running in a single process, but it sounds to me like you also want centralized configuration (as you mention, with an organisational unit effectively being the domain name).

Proposal: if caddy is started with a single servertype, the caddyfile operates as it does currently. Everything is implicitly scoped with that server type.

If it’s started with multiple servertypes, all directives must be explicitly enclosed in a servertype block at some point. Each server only gets the directives for its type.

I guess I should do this generic TLS proxy and then have a try at making this work, rather than just talking about it :smiley: :smiley: :smiley:

I could probably do the scheme above as a “multi-server” server type, actually.

Your proposed syntax won’t work though, some server types have no notion of hostnames or sites or web addresses or whatever they are.