- 3D transforms: We got feedback before that people really liked them, for example: https://news.ycombinator.com/item?id=23072414 -- they're not extreme, which we tried to avoid. I guess some people will like them and others won't... personally I think they make it visually interesting and draw attention and are still quite legible. That's me though.
- Words: Yeah, it's long. I want to break things out into more pages so that each section has its own page, eventually, but life got busy so I had to kind of consolidate for now.
- Grandiose claims: I _believe_ everything we've written is accurate/true, many of which cite original sources. Maybe some claims have multiple interpretations or contexts (e.g. I'd wager "more secure, more reliable, and more scalable than any other solution" is true in many ways, even if it's not always the right tool in every situation). I'll review to make sure we're avoiding false hyperbole but from what I can recall, I stand by what the page claims.
- Switching from Nginx: I was hoping our homepage was able to convey that even though you can have automatic HTTPS with other servers, they don't come with it built-in or on by default, which Caddy does; and even if you do have auto HTTPS, Caddy's is _better_ (for various reasons explained on the page). I think we directly address competition like nginx in several places, such as simpler configs, memory safety, etc. Maybe I need to make it more obvious. Actually, I want to have a dedicated Compare page where we compare Caddy with other software.
- Fewer moving parts: We're saying that the moving parts are optional, I guess. Of course you can run Caddy in a cluster and it works really well in that setup, but you don't _NEED_ to do that probably; and even if you do, you don't need extra tools, libraries, scripts, or utilities that you often need with other solutions. I'll try to clarify that in the wording.
_> The main reason I haven't really tried Caddy is because Nginx already works fine and I don't want to learn a new config format and ecosystem._
Fair. (You can actually keep your config format, Caddy has an nginx adapter you can run it with.)
> Is there really an ROI for a migration and the learning that needs to come with it?
For many companies/professionals, _yes_ Caddy definitely saves a lot of time, technical complexity, and even prevents expensive downtime. Some of the testimonials on the homepage refer to this, like the organization that put Caddy in front of a service last-minute that was about to fail their PCI compliance audit.
Tell me more about your use case and what pain points you do have!
> Tell me more about your use case and what pain points you do have!
I don't have pain points with my reverse proxy or auto tls. I honestly don't want a reverse proxy that does auto TLS by default. I put it more places where it is not needed and would prefer to opt in when/where needed.
> I _believe_ everything we've written is accurate/true, many of which cite original sources.
I see one section that does this with questionable value. That section actually decreased my trust. They are 5+ years old and the one I looked at in detail (third) only mentions caddy in one sentence. I would not put something like that as "proof" on a website. I understand you believe these things, but now I believe and trust less.
- 3D transforms: We got feedback before that people really liked them, for example: https://news.ycombinator.com/item?id=23072414 -- they're not extreme, which we tried to avoid. I guess some people will like them and others won't... personally I think they make it visually interesting and draw attention and are still quite legible. That's me though.
- Words: Yeah, it's long. I want to break things out into more pages so that each section has its own page, eventually, but life got busy so I had to kind of consolidate for now.
- Grandiose claims: I _believe_ everything we've written is accurate/true, many of which cite original sources. Maybe some claims have multiple interpretations or contexts (e.g. I'd wager "more secure, more reliable, and more scalable than any other solution" is true in many ways, even if it's not always the right tool in every situation). I'll review to make sure we're avoiding false hyperbole but from what I can recall, I stand by what the page claims.
- Switching from Nginx: I was hoping our homepage was able to convey that even though you can have automatic HTTPS with other servers, they don't come with it built-in or on by default, which Caddy does; and even if you do have auto HTTPS, Caddy's is _better_ (for various reasons explained on the page). I think we directly address competition like nginx in several places, such as simpler configs, memory safety, etc. Maybe I need to make it more obvious. Actually, I want to have a dedicated Compare page where we compare Caddy with other software.
- Fewer moving parts: We're saying that the moving parts are optional, I guess. Of course you can run Caddy in a cluster and it works really well in that setup, but you don't _NEED_ to do that probably; and even if you do, you don't need extra tools, libraries, scripts, or utilities that you often need with other solutions. I'll try to clarify that in the wording.
_> The main reason I haven't really tried Caddy is because Nginx already works fine and I don't want to learn a new config format and ecosystem._
Fair. (You can actually keep your config format, Caddy has an nginx adapter you can run it with.)
> Is there really an ROI for a migration and the learning that needs to come with it?
For many companies/professionals, _yes_ Caddy definitely saves a lot of time, technical complexity, and even prevents expensive downtime. Some of the testimonials on the homepage refer to this, like the organization that put Caddy in front of a service last-minute that was about to fail their PCI compliance audit.
Tell me more about your use case and what pain points you do have!