You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is because Dreamhost does not support access controls based on project. If we want to deploy from GitHub with deployment credentials that have limited access (read: cannot mess with other deployment, whether by accident or due to malicious compromise), we'd have to:
Create separate user credentials for every separately deployed project, which I don't think can be done programmatically.
Separate any projects that currently deploy to a shared domain (e.g. experiments.cubing.net).
I think that this would make debugging unnecessarily painful.
That said, Dreamhost has been stable for serving files1 and gives us flexibility for some things we might need in the future2. It's also much, much, much faster to deploy than GCE and AWS Lambda, and I'd prefer to avoid any flashy hosting service that might disappear or sell us out on a timespan of 10 years.
I think a medium-term approach might be to have GitHub Actions trigger a simple cgi-bin setup in Dreamhost that pulls and deploys an artifact from GitHub Pages. As a long-term solution, I'd love to find something that's similar to Dreamhost but based on Caddy. I'm reluctant to self-host — as much as we have the resources and skills to do so — since that can more easily lead to uptime or maintenance challenges compared to shared hosting3.
Footnotes
If you overlook their atrocious track record of failing to renew HTTPS certificates. But at least I have a monitoring service for that. ↩
Like a simple database or simple site templating. The latter is unfortunately necessary due to badly designed things like the Open Graph protocol. This could be solved by using a cloud worker using something like the HTMLRewriter API, but that requires additional configuration and maintenance. ↩
Moved from: #3
Right now we mainly have two kinds of deployment:
This is because Dreamhost does not support access controls based on project. If we want to deploy from GitHub with deployment credentials that have limited access (read: cannot mess with other deployment, whether by accident or due to malicious compromise), we'd have to:
experiments.cubing.net
).I think that this would make debugging unnecessarily painful.
That said, Dreamhost has been stable for serving files1 and gives us flexibility for some things we might need in the future2. It's also much, much, much faster to deploy than GCE and AWS Lambda, and I'd prefer to avoid any flashy hosting service that might disappear or sell us out on a timespan of 10 years.
I think a medium-term approach might be to have GitHub Actions trigger a simple
cgi-bin
setup in Dreamhost that pulls and deploys an artifact from GitHub Pages. As a long-term solution, I'd love to find something that's similar to Dreamhost but based on Caddy. I'm reluctant to self-host — as much as we have the resources and skills to do so — since that can more easily lead to uptime or maintenance challenges compared to shared hosting3.Footnotes
If you overlook their atrocious track record of failing to renew HTTPS certificates. But at least I have a monitoring service for that. ↩
Like a simple database or simple site templating. The latter is unfortunately necessary due to badly designed things like the Open Graph protocol. This could be solved by using a cloud worker using something like the
HTMLRewriter
API, but that requires additional configuration and maintenance. ↩Say what you want about Dreamhost, but https://live.deprecated.cubing.net/StanfordFall2011/ is still running perfectly over 13 years later without any human maintenance. ↩
The text was updated successfully, but these errors were encountered: