3 ms·
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
by andmarios 9y ago
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
- Whitestrake 9y agoTo compile without the `Caddy-Sponsors` header, include this line before the plugin comment: sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.go
- andmarios 9y agoThanks, 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.
- tylersmith 9y agoThis 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.