Skip to main content
We love Caddy! Like MagicServer, Caddy offers automatic HTTPS, and was the inspiration for the project! If you are already using Caddy, you probably don’t need MagicServer. As a library, however, MagicServer offers important advantages.

​
Simplicity

While it requires minimal configuration, Caddy needs to be installed separately. It’s an additional piece of software to wrangle, and if you are working within a team, to document. Making use of MagicServer requires no changes to how you build and deploy. It runs within the single process of your application; one less moving part to worry about.

​
Performance

Routing requests through a reverse proxy introduces a performance overhead. MagicServer handles TLS termination directly in your process. Zero network hops, zero proxy overhead. Your application serves HTTPS requests directly, achieving lower latency and higher throughput.

​
Advanced Use Cases

Since Caddy runs as an independent process, it can route requests to multiple applications, all while serving the same domain with HTTPS! This allows you to run a single site with parts provided by different applications, which may be written in different programming languages, a feature not possible with MagicServer. Additionally, Caddy is a pioneer in all things ACME. It is feature packed for all sorts of niche requirements, like wildcard certificates and ARI extension. Though actively developed, MagicServer focuses on the most common use cases. As your needs grow, you may want to consider Caddy.

​
Conclusion

We believe Caddy has its place, but it’s not challenging MagicServer’s. MagicServer targets the most common scenario: one application, one domain, effortless HTTPS. If that describes your use case, MagicServer delivers automatic HTTPS with less complexity, better performance, and zero operational overhead. Choose simplicity when you can. Upgrade to complexity when you must.
⌘I