Hacker News Reader

Comment by mholt | Hacker News Reader

D'aww, thank you!

I was really nervous to post this on HN because HN has also been the source of great misery for me in the past, frankly. But I'm relieved at the overall positivity today. Maybe because it's Star Wars Day we're all in a good mood?

I'm glad you like the landing page. Took me a couple weeks of trying and throwing designs away, then a few days of concerted effort, just standing in front of my text editor cranking out HTML and CSS best I could muster. The visual touches aren't perfect but I'm quite pleased.

... come to think of it, reading the criticism from HN on other projects made me hyper-aware of certain things, like explaining what the product actually does, and how to lay it out, and not mess with scrolling, etc etc. (But not the toxic comments, I skip those.)

View on HN

You have a really impressive site about a really impressive product. Kudos.

The only constructive criticism I'd offer immediately for the new updates is that they look very light on detail about setting up a production deployment on different platforms -- things like running Caddy as a service that starts automatically, monitoring its health and restarting if necessary, ensuring that any important security updates are known about and installed, etc. It's great to have so much that "just works" and a simple developer experience demonstrated immediately, but the other stuff is still important too.

Edit: I see https://caddyserver.com/docs/install now talks about some of these issues for Caddy 2. In that case, perhaps it would be useful to add a prominent link there from the v2 page at https://caddyserver.com/v2? I was half-expecting the "Download" button to take me to such a page, and was very surprised to find myself sent to GitHub (particularly since there are neither instructions about downloading nor visible links to the assets to download actually visible on the GH page you arrive at).

Thanks -- honestly, the website was the least of my concerns up to this point, but it'll get more attention now that the software is actually released.

In that case, having a smart and informative site already is even more of an impressive achievement. :-)

I don't personally think much needs to change dramatically. It's already useful and seems reasonably well organised. As someone who hadn't previously heard of Caddy other than incidentally and who is currently setting up some new projects for which Caddy is a very interesting find this evening, that production-ready setup information is the key information that was missing for me until I found the other page (and as it happens, I found it via a link that wingworks helpfully posted in this HN discussion, not via browsing the Caddy site or a search engine).

If I were to add one other possibly helpful point, the configuration via HTTP request idea is interesting, but everywhere I've seen it mentioned on the site so far seemed to imply it is on by default and did not say anything about locking it down. Again, this looks potentially useful for a quick start experimenting with Caddy or maybe for development purposes, but it doesn't seem like a killer feature and it's obviously a concern for using it in production if anything like that doesn't default to safe.

Please do try to mount an attack on your server's admin endpoint; let me know if you're able to break into it.

Keep in mind that if your system runs untrusted code, all bets are off: there's not really anything we can do as a single user space process to protect it. If your system runs untrusted code, you'll need to make sure your system is locked down properly... maybe you can use a permissioned unix socket for the admin endpoint, or just disable it entirely... it's really up to you. I think our defaults are safe though. Let me know if they aren't.

Sorry, maybe I wasn't clear.

I was trying to explain that during my initial browsing of the Caddy site, I found several references to using the API endpoints to configure Caddy, but nothing in the same places to say how to secure it or whether it was enabled by default. I wasn't talking about any sort of cunning attack, simply the issue of having such functionality accessible to anyone who could visit /config/ and knew anything about HTTP.

I did later discover the relevant configuration in the JSON config structure documentation, including the flag to disable it that is what I really wanted to know about. It just seemed like the kind of important detail that would be worth linking from places that introduce the REST API, such as the section about it on your v2 landing page, if you're refining the site.

My understanding is that the config is available via localhost only. It most instances it does not need to be disabled. I think the hope is that it will be left enabled in production, not disabled.

You mean because it's on a different port that typically wouldn't be opened in the firewall to allow remote access?

The default listen address is "localhost:2019", which means it'll only accept requests from apps running on the same machine. If you're running untrusted code on the same machine, then that might be problematic for you. You can also change the admin endpoint to be a unix socket instead of a TCP endpoint which allows you to use linux file permissions to protect it.

Forget the misery. Caddy has been sheer wonder to work with since more or less the beginning. 2.0 in beta and RC has been looking swell for a long time. Well done and congratulations to you.

It's a one-way street, though. Once I'd set up my first Caddy site, there really wasn't any way I was ever going back to the legacy stacks.

the landing page almost looked too slick and polished! i thought it was a for sale program instead of an open source one at first. neat tool... thanks for sharing it

Reply on news.ycombinator.com