Is there a way to write caddy v2 plugins in another language?

Please correct me if I am wrong but caddy v2 is like the previous Linux unikernel design where if you wanted to add a plugin to your caddy v2 service, you will have to:

  1. Write that plugin in Go
  2. Compile caddy with this plugin (alongwith other plugins) that you want in your caddy v2 service

Which means that:

  1. You cannot write caddy v2 plugins in another language, only Go?
  2. You cannot “drop in” or “take out” a plugin and restart caddy but literally have to compile caddy on every plugin change

Are these 1 - 4 all accurate?
In that case:

  1. Is there a caddy v2 plugin that perhaps allows a way for an external service to act as a caddy middleware, say over HTTP or gRPC? (by being a middleware, it will affect how caddy behaves - like a plugin would but be more limited/might lack a lot of the features a native Go plugin can expose)
  2. Lacking that, is there any way to kind of achieve the same effect as writing a simple plugin that’s not very featureful, but in another language than Go - I’m thinking like FastCGI but for affecting caddy’s behavior itself?

Hi @JnAlu,

Yes, 1-4 are accurate. (For the reference of any other readers, there is documentation on this here: Extending Caddy — Caddy Documentation).

Regarding 5 and 6, there’s lots of things you can do just using Caddy to select for specific kinds of requests and forward them via HTTP reverse proxy to an appropriate application server, which you could write in any language and could have whatever logic you want. This, of course, exports your “middleware” beyond the realms of Caddy’s ongoing state - which would be the case with any kind of programming language jump you could possibly implement anyway.

What kind of Caddy behaviour are you looking to have your middleware alter? Can you achieve these alterations via the JSON API?


Here’s my immediate usecase:

It’s possible that this immediate usecase can be resolved just by affecting the HTTP request-response payloads (so FastCGI could work) but I wanted to learn about ways where more advanced behavior would be needed (for example, if I wanted to persist caddy config in Hashicorp Consul or secrets in Hashicorp Vault)

You mean API — Caddy Documentation

It looks like an admin API instead of being able to help with a plugin/module.

We can discuss here or at How can I configure caddy v2 to be an API proxy that can persist cached responses? , but I am having a tough time visualizing how I can use this API to:

  • cache responses
  • rewrite the API key in requests

You can use another caching platform as a middle-man (literal middleware, just not integrated directly into Caddy) in a reverse proxy chain to achieve this.

HAProxy sounds like a great candidate, for example. Caching API responses is a very, very common use case for that platform, I understand.

Caddy itself can handle the API key rewriting with relative ease if we’re talking about headers. It can also map a list of arbitrary ApiKey1ApiKey2 pairs: map (Caddyfile directive) — Caddy Documentation

Or that could also be handled in HAProxy or some other appropriate discrete software in the reverse proxy chain.


This topic was automatically closed after 60 days. New replies are no longer allowed.