Hacker News new | past | comments | ask | show | jobs | submit login

Not being able to use the release binaries (even from github) for commercial purposes is a bummer but if this is the price to pay for having caddy available as open source, then it is fair.

What I am afraid of, is that this friction to start with caddy (because $50 per month is way too much for most use cases) will affect its user base and as a consequence the participation in development. Of course mholt and the team behind caddy are the people who love it the most and care about its future the most, so I trust they will keep pushing forward.

For people who find it difficult to build caddy from source, here is an example, provided you have Go installed and configured:

  go get github.com/mholt/caddy
  go get github.com/caddyserver/builds
  
  cd "$GOPATH/src/github.com/mholt/caddy/caddy"

  # Enable cors, prometheus plugins.
  cat <<EOF>caddymain/plugins.go
  package caddymain
  
  import (
          _ "github.com/captncraig/cors/caddy"
          _ "github.com/miekg/caddy-prometheus"       
  )
  EOF
  
  go get -u -v -f ... || echo "Updated dependencies"
  go run build.go
Edit: updated with the latest build procedure



To compile without the `Caddy-Sponsors` header, include this line before the plugin comment:

    sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.go


Thanks, although I personally will keep it. When I was maintaining web servers as a living I used to add a custom header here and there, so I see no harm in the practice.


This only helps until they start injecting data in different places. Maybe soon they'll add HTML comments or JavaScript to popup a notification. Now that they've shown they don't care about users' data security I don't know why anybody would expect them to stop here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: