I recently put hasura behind an nginx reverse proxy. Because I was also serving static files along with other services, I had to explicitly call out the hasura endpoints. Getting this set up to allow console access was more challenging and took longer than expected as I didn't realize I needed to open access to /v1/ in addition to /v1alpha1.
It seems that '/v1/*' is only needed for cli and console access, suggesting that in production external access can be disabled.
It would be useful to have documentation of the endpoints that hasura uses or perhaps an advanced production deployment guide using a more complex reverse proxy.
Nginx seem to require some special config to proxy pass both http and websocket on one url: https://serverfault.com/questions/910805/proxy-websockets-and-http-through-the-same-location-in-nginx
Apache is also quite popular
For future reference to documentation:
I tried to serve the console at http://myserver.com/hasura using nginx (as a reverse proxy) but got mixed results. @shahidhk advised me to use the following nginx config which worked flawlessly:
location /hasura/ {
proxy_pass http://localhost:8080/;
# for websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
The point is, the trailing slashes in the config is important. I'm not using websockets so can't vouch for it but this reverse proxy config just works without any changes to how hasura is deployed.
Without the trailing slashes I'd get the following response:
{"path":"$","error":"resource does not exist","code":"not-found"}
The above NGINX config didn't work for me (websockets didn't work) but the following config does:
map $request_method $connection_header {
default '';
GET 'upgrade';
}
map $request_method $upgrade_header {
default '';
GET 'websocket';
}
server {
listen 80;
server_name localhost;
location = /hasura/v1/graphql {
rewrite /hasura/v1/graphql /v1/graphql break;
proxy_pass http://hasura:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $upgrade_header;
proxy_set_header Connection $connection_header;
proxy_connect_timeout 1d;
proxy_send_timeout 1d;
proxy_read_timeout 1d;
}
location / {
root /frontend-dist;
try_files $uri $uri/ /index.html;
}
}
It is a bit of a hack though, as it relies on the fact that only the websocket handshake makes a GET request on the endpoint (at least in our setup).
Caddy config:
my-domain.com/hasura {
proxy graphql-engine:8080
websocket
without /hasura
}
this will serve hasura at mydomain.com/hasura. If it should be only mydomain.com, remove the path from the first line and remove the without line
Same issue with Hasura over Caprover, with reverse proxy Nginx (a self hosted PaaS like heroku).
For the subscription i can't connect with hasura over ws with firefox, but Chrome is ok.
I can configure the NGinx Config file, but none of yours work with Firefox. Everythings fine with Chrome but not firefox, that's very weird.
Caddy is work as documentation. However, an example by Nginx for the reverse proxy is still has an issue.
location /hasura/ {
proxy_pass http://localhost:8080/;
# for websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Any documents for nginx ingree to use reverse proxy?
Defaut endpoint URL hasura graphql http://localhost:8080/v1/graphql, we can convert it use nginx reverse proxy, for example to be http://localhost/api/v1/graphql
Below my nginx conf
# define upstream
upstream api {
server graphql-engine:8080;
}
server {
# other conf
location /api/v1/graphql {
proxy_pass http://api/v1/graphql;
}
}
Now, endpoint URL to be http://localhost/api/v1/graphql
Its work for me
Most helpful comment
For future reference to documentation:
I tried to serve the console at http://myserver.com/hasura using nginx (as a reverse proxy) but got mixed results. @shahidhk advised me to use the following nginx config which worked flawlessly:
The point is, the trailing slashes in the config is important. I'm not using websockets so can't vouch for it but this reverse proxy config just works without any changes to how hasura is deployed.
Without the trailing slashes I'd get the following response:
{"path":"$","error":"resource does not exist","code":"not-found"}