5 ms·

> It's fairly common to use git repositories as a vehicle for serving websites. The webdev pushes their changes to some branch of a publicly available git repos

by sho 3y ago

> It's fairly common to use git repositories as a vehicle for serving websites. The webdev pushes their changes to some branch of a publicly available git repository This doesn't require the git repo to be public. My go-to "day one" static website deploy strategy is to set up a git remote on some VPS, point nginx at its public html folder, then "deploy" to that with a git push, authed by ssh key. You'd be surprised how far you can get with simple tricks like this. I served about the first 6 months of what would become a multi-hundred-million company with this hilariously simple setup running on a $20/m DO VPS.

p4bl0 3y ago
I've been publishing my personal web page like this for more than 15 years now (the repos log history goes back to early 2009). I use a post-update hook that makes sure on each push that the working directory is on par with the master branch (so that things that are pushed to other branches aren't made public) and then the public site is rebuilt (using a Makefile and custom scripts making heavy use of xml2, 2xml, sed, and the coreutils, but that's another story). I can see why the author of the linked blog post would want to serve directly from the Git repository: it's fun. But I agree that it seems uselessly inefficient compared to (re)generating a static version of the site only when changes occur. If there is no processing needed like in the case of the blog post, a simple post-update hook can easily do the trick: go to the public directory served by the web server, then set the GIT_DIR environment variable to point to the .git directory of your repository, then execute the command `git checkout main-branch -- .` to get all the static files out of the repository). This would then have the exact same external behavior as what is proposed in the linked blog post, but will be way more efficient (except of course if you have no visitors and update your website very very often).
supriyo-biswas 3y ago
This approach is fine for static websites, but for web applications you should probably block requests to /.git so that people can’t clone your application off of the web.
- p4bl0 3y ago
  The .git directory doesn't necessarily need to be in the public directory at all.
  - quectophoton 3y ago
    If anyone wants to read more about this, search for `GIT_DIR` and `GIT_WORK_TREE` environment variables.
    - trifurcate 3y ago
      Or, put your files under html/ in your repo, and push to /var/wwwroot (using the common /var/wwwroot/html setup)
  - ozim 3y ago
    It is always good reminder anyway to tell people to either make public dir not root of repo or block .git.
geek_at 3y ago
I do the same. My blog on a 9€/mo Contabo VPS survived multiple HN/Reddit hugs. Lateley I've been playing with more configuration options like I have two servers configured behind a load balancer but with a heavy focus on server 1. Only if the response time of server 1 is under 500ms, server two is used, which hosts an almost identical site but with ads. So under normal circumstances nobody will see ads on my blog unless I get a huge spike (more than 600 concurrent users ususall)
throwaway828 3y ago
What was your multi hundred million dollar company?
- sho 3y ago
  Unfortunately, it wasn't my hundred million dollar company.
dirkc 3y ago
If you're just serving static files, wouldn't a S3 website be easier and more robust?
- 0xFF0123 3y ago
  With unbounded running costs... There is something comforting about knowing it's always going to cost you $20.
  - dirkc 3y ago
    True, didn't think about it from the limited cost perspective. Would be a lot of traffic to get you past $20, but a possibility like you say.
    - sitkack 3y ago
      Put CF in front of that VPS and it is better than S3.
      - cpach 3y ago
        One can also have CloudFront before S3, IIRC.
        dirkc 3y ago
        That is my goto setup for static or semi-static sites. In theory you could still see a runaway bill with CloudFront, although I haven't checked the numbers to actually see what magnitude of traffic would be needed for it to really hurt? *edit* did a quick check, based on my definition of hurt about 1,000 request per second sustained for the month or > 12TB traffic would hurt. But then again, I'm sure there is some other weird edge case that AWS bills for that could incur more severe costs with less traffic. And that is what I take 0xFF0123 to imply
- foldr 3y ago
  Last time I checked it was a bit clunky to get these working with HTTPS.
qudat 3y ago
Oh I really like that idea! Over at pico.sh we are trying to make it dead simple to host N static sites using common tools: rsync, scp, and sftp. https://pgs.sh https://pgs.sh It really should be as simple as you are describing!

by sho 3y ago

p4bl0 3y ago

I've been publishing my personal web page like this for more than 15 years now (the repos log history goes back to early 2009). I use a post-update hook that makes sure on each push that the working directory is on par with the master branch (so that things that are pushed to other branches aren't made public) and then the public site is rebuilt (using a Makefile and custom scripts making heavy use of xml2, 2xml, sed, and the coreutils, but that's another story). I can see why the author of the linked blog post would want to serve directly from the Git repository: it's fun. But I agree that it seems uselessly inefficient compared to (re)generating a static version of the site only when changes occur. If there is no processing needed like in the case of the blog post, a simple post-update hook can easily do the trick: go to the public directory served by the web server, then set the GIT_DIR environment variable to point to the .git directory of your repository, then execute the command `git checkout main-branch -- .` to get all the static files out of the repository). This would then have the exact same external behavior as what is proposed in the linked blog post, but will be way more efficient (except of course if you have no visitors and update your website very very often).

supriyo-biswas 3y ago

This approach is fine for static websites, but for web applications you should probably block requests to /.git so that people can’t clone your application off of the web.

p4bl0 3y ago
The .git directory doesn't necessarily need to be in the public directory at all.
- quectophoton 3y ago
  If anyone wants to read more about this, search for `GIT_DIR` and `GIT_WORK_TREE` environment variables.
  - trifurcate 3y ago
    Or, put your files under html/ in your repo, and push to /var/wwwroot (using the common /var/wwwroot/html setup)
- ozim 3y ago
  It is always good reminder anyway to tell people to either make public dir not root of repo or block .git.

geek_at 3y ago

I do the same. My blog on a 9€/mo Contabo VPS survived multiple HN/Reddit hugs. Lateley I've been playing with more configuration options like I have two servers configured behind a load balancer but with a heavy focus on server 1. Only if the response time of server 1 is under 500ms, server two is used, which hosts an almost identical site but with ads. So under normal circumstances nobody will see ads on my blog unless I get a huge spike (more than 600 concurrent users ususall)

throwaway828 3y ago

What was your multi hundred million dollar company?

sho 3y ago
Unfortunately, it wasn't my hundred million dollar company.

dirkc 3y ago

If you're just serving static files, wouldn't a S3 website be easier and more robust?

0xFF0123 3y ago
With unbounded running costs... There is something comforting about knowing it's always going to cost you $20.
- dirkc 3y ago
  True, didn't think about it from the limited cost perspective. Would be a lot of traffic to get you past $20, but a possibility like you say.
  - sitkack 3y ago
    Put CF in front of that VPS and it is better than S3.
    - cpach 3y ago
      One can also have CloudFront before S3, IIRC.
      - dirkc 3y ago
        That is my goto setup for static or semi-static sites. In theory you could still see a runaway bill with CloudFront, although I haven't checked the numbers to actually see what magnitude of traffic would be needed for it to really hurt? *edit* did a quick check, based on my definition of hurt about 1,000 request per second sustained for the month or > 12TB traffic would hurt. But then again, I'm sure there is some other weird edge case that AWS bills for that could incur more severe costs with less traffic. And that is what I take 0xFF0123 to imply
foldr 3y ago
Last time I checked it was a bit clunky to get these working with HTTPS.

qudat 3y ago

Oh I really like that idea! Over at pico.sh we are trying to make it dead simple to host N static sites using common tools: rsync, scp, and sftp. https://pgs.sh https://pgs.sh It really should be as simple as you are describing!