Wedge is a general-purpose HTTP/2 web server that serves HTTPS by default.
Wedge is a fork of Caddy, with sponsor headers removed. The project is unofficial.
As a result of issue #2, references to Caddy in this documentation are being changed to reference the name "Wedge" instead.---
Wedge is fast, easy to use, and makes you more productive.
Available for Windows, Mac, Linux, BSD, Solaris, and Android.
go get github.com/WedgeServer/builds go get github.com/WedgeServer/wedge/caddy
go run build.go.
- Easy configuration with the configuration file
- Automatic HTTPS on by default (via Let's Encrypt)
- HTTP/2 by default
- Virtual hosting so multiple sites just work
- Experimental QUIC support for those that like speed
- TLS session ticket key rotation for more secure connections
- Extensible with plugins because a convenient web server is a helpful one
- Runs anywhere with no external dependencies (not even libc)
Follow the instructions above for building from source. Binaries will be available soon.
To serve static files from the current working directory, run:
The default port is 2015, so open your browser to http://localhost:2015.
Go from 0 to HTTPS in 5 seconds
If the binary has permission to bind to low ports and your domain name's DNS records point to the machine you're on:
wedge -host example.com
This command serves static files from the current directory over HTTPS. Certificates are automatically obtained and renewed for you!
Customizing your site
To customize how your site is served, create a file named Wedgefile by your site and paste this into it:
localhost push browse websocket /echo cat ext .html log /var/log/access.log proxy /api 127.0.0.1:7005 header /api Access-Control-Allow-Origin *
When you run
wedge in that directory, it will automatically find and use that Wedgefile.
This simple file enables server push (via Link headers), allows directory browsing (for folders without an index file), hosts a WebSocket echo server at /echo, serves clean URLs, logs requests to an access log, proxies all API requests to a backend on port 7005, and adds the coveted
Access-Control-Allow-Origin: * header for all responses from the API.
Wow! Wedge can do a lot with just a few lines.
Doing more with Wedge
It is possible to host multiple sites and customise the web server using the configuration file.
Sites with qualifying hostnames are served over HTTPS by default.
Wedge has a command line interface. Run
caddy -h to view basic help.
Running in Production
Wedge is production-ready if you find it to be a good fit for your site and workflow.
Running as root: We advise against this. You can still listen on ports < 1024 on Linux using setcap like so:
sudo setcap cap_net_bind_service=+ep ./caddy
How you choose to run Wedge is up to you. Many users are satisfied with
nohup wedge &. Others use
screen. Users who need Wedge to come back up after reboots either do so in the script that caused the reboot, add a command to an init script, or configure a service with their OS.
If you have questions or concerns about Wedge' underlying crypto implementations, consult Go's crypto packages, starting with their documentation, then issues, then the code itself; as Wedge uses mainly those libraries.
Please see our contributing guidelines for instructions.
We use GitHub issues and pull requests only for discussing bug reports and the development of specific changes.
Thanks for making Wedge -- and the Web -- better!
About the Project
Wedge was created following the announcement that sponsor headers would be added to HTTP responses, and official binaries would no longer be able to be used for commercial purposes.
See the HackerNews post.