Open gedw99 opened 4 weeks ago
Does this also hold the request whilst the docker is being started up ?
The blocking strategy holds the request until the docker container is up and ready. So that takes into account starting up the docker container.
I know caddy natively supports this if it’s configured . It will wait for the proxied app to start up and then let the request through .
Do you mean the Sablier plugin ? Or Caddy itself ? If so, could you please share some documentation about that behavior.
It would be cool if you could just set up the GitHub repo that a caddy proxy represents . Then when a request comes in , it would pull the docker that was build to run the repo , and then pull the repo contents .
it would make it easy to run hugo based projects where the markdown is produced after the repo with the markdown is pulled or js based projects where the code would be compiled after the repo is pulled .
So instead of linking pre-built containers, you'd want to be able to link not-yet-built containers ?
Could you give an example on how you'd configure this as if this feature existed ?
Like how would you configure the reverse proxy, the sablier plugin and sablier itself.
Hey @acouvreur
in caddy it uses the “try” keyword in the config .
I tried to find an example for it but could not find though .
Does this also hold the request whilst the docker is being started up ?
I know caddy natively supports this if it’s configured . It will wait for the proxied app to start up and then let the request through .
It would be cool if you could just set up the GitHub repo that a caddy proxy represents . Then when a request comes in , it would pull the docker that was build to run the repo , and then pull the repo contents .
it would make it easy to run hugo based projects where the markdown is produced after the repo with the markdown is pulled or js based projects where the code would be compiled after the repo is pulled .