I don’t use Heroku, so I couldn’t say. You also haven’t said what kind of app you’re trying to serve with Caddy.
These lines are not necessary. Caddy sets the appropriate headers automatically, see in the docs:
Also in Caddy v2, the option is called header_up, not header_upstream. You probably found instructions for Caddy v1. Caddy v2 is a complete rewrite and is fundamentally quite different.
This doesn’t really make sense. You can’t proxy to the same domain that you’re serving, otherwise you’ll just end up in an infinite loop.
It’s my first time setting up a reverse proxy, so I don’t know much about it.
I have a node app that is built with Sapper.
How would I write the Caddyfile to simply route http requests to https? Heroku uses dynamic IPs that change all the time.
Heroku dynos are virtualized Linux containers, but I haven’t really used any other platform. How would you typically run Caddy and a node app at the same time?
I think there are some terms to be clarified before delving into solving the problem of how to configure Caddy for your use-case.
Heroku is member of category of services known as PaaS (Platform-as-a-Service). This type of services handle the infrastructure for you, meaning it will take care of the OS, installing necessary prerequisite software/packages, and managing the traffic directed to your application. You must satisfy the needs of your app by what the service provides you, which might include managing the TLS certificates to enable HTTPS for the app. To cut the long story short, Heroku will enable HTTPS for your app within certain conditions. You must read these two pages of Heroku documentation site to understand the requirements:
That said, let me explain why Caddy isn’t compatible with Heroku. Caddy, as a web server, does not fit within Heroku. Heroku might be using it, or some other web server, as part of their infrastructure, but they don’t extend such control to the users. Caddy is intended for use on IaaS (Infrastructure-as-a-Service) and on-premise. Examples of IaaS include Azure, DigitalOcean, and Linode. IaaS is basically any provider who gives you access to remote virtual machine, and it’s up to you as the consumer to set it up to fit the needs of your application. Heroku does not give you such access. You tell Heroku what you need, give Heroku a packaging of your app, and Heroku will set up the necessary infrastructure in a manner that is invisible to you.
Caddy assumes you have access to the OS to install and configure as necessary. The web server is responsible for serving the files requested by the browser, fetching part of the response from other server (i.e. reverse-proxy), manipulate the response, and reply to the client (browser). This is part of what Caddy does, which interferes greatly with Heroku’s own providing because it’s not intended for its class of providers.
If you’re using Heroku and it’s fulfilling your needs except for HTTPS, then you can have the S via Heroku themselves. You just had to find the right documentation pages.