Reverse-Proxy

ToolJet makes it very easy to wire up APIs, databases, and internal tools fast. Then CORS shows up and ruins your afternoon. If you are building ToolJet apps that call APIs from the browser, CORS is one of those constraints you cannot brute-force away. You either design around it, proxy around it, or configure it correctly on the server. There is no frontend-only hack that “disables CORS” in production. If somebody suggests a browser extension, close the tab. ...

CORS in Traefik is mostly a headers middleware problem. Once you get that, the config becomes pretty mechanical. The annoying part is that browsers are strict, Traefik is flexible, and bad examples online often mix app-level CORS with proxy-level CORS. I usually prefer handling CORS at the edge in Traefik when multiple services need the same behavior. It keeps backend apps simpler and avoids five different teams all inventing slightly broken header logic. ...

Caddy makes the easy path easy, but CORS is still CORS. The browser enforces it, the server has to answer correctly, and one wrong header can turn a simple API call into a weird frontend bug that eats an afternoon. This guide is the version I wish I had the first few times I configured CORS behind a reverse proxy. What CORS is actually doing CORS is the browser asking: ...

I’ve seen the same CORS mess play out on Hetzner boxes more than once: the app works locally, staging kind of works, then production starts throwing browser errors that look random until you realize the reverse proxy, the API, and the frontend all disagree about who is allowed to talk to whom. This case study comes from a very normal setup on Hetzner Cloud: frontend on app.example.com API on api.example.com Nginx on the VPS as reverse proxy Node.js API behind it TLS terminated at Nginx a second environment for previews on *.staging.example.com The team had deployed cleanly. DNS was right. Certificates were fine. Curl looked fine. The browser was not fine. ...