Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static site hosting hurdles

notes.volution.ro

Post reply on HN
Print view View original

71–80 of 183 posts

Re: Static site hosting hurdles

#71

Post by bachmeier »

chubot wrote: post #64
laundermaf wrote: post #59

Earlier quoted context omitted.

> what's wrong with shared hosting? You answered that yourself: > It costs less than $10/month That’s a lot of dollars for a static website. There are a myriad of free options and there have been for years. Kinda disappointing that they weren’t mentioned. Anyone wanting to deploy a static website knows the big 4, completely free: Netlify, Vercel, CloudFlare Pages, GitHub Pages.

I prefer not to use free services because they're not sustainable, and they usually come with strings attached Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years) The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/ I thought mine was more like $8 but…

> I prefer not to use free services because they're not sustainable

Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.

Re: Static site hosting hurdles

#72

Post by pdimitar »

laundermaf wrote: post #61
esperent wrote: post #30

I switched from Vercel static site hosting, because I recently read an article here about how it's usually more economical to scale vertically instead of horizontally (i.e. use one big server for everything). Even though I'm only running a few services, I did the math and realized it's absolutely true. I can fit everything I'm running onto one DigitalOcean droplet behind Cloudflare for $24/month + an extra 25gb block…

The other problem is that one goes down, they all go down. A static website has absolutely no reason to go down.

Hardly a problem for a personal blog.

I host a few things on my baremetal server at home. When I get kernel updates (2-3 times a month) the Docker container with the Pi-Hole is rebooted and for 30 secs DNS resolution doesn't work in our home network. I probably can fix that by changing the script to do blue-green deployment (only stop the container after a new one has been brought up) but it honestly isn't such a problem.

If it bothers me I will likely spend no more than one hour to fix it.

Re: Static site hosting hurdles

#74

Post by esperent »

laundermaf wrote: post #61
esperent wrote: post #30

I switched from Vercel static site hosting, because I recently read an article here about how it's usually more economical to scale vertically instead of horizontally (i.e. use one big server for everything). Even though I'm only running a few services, I did the math and realized it's absolutely true. I can fit everything I'm running onto one DigitalOcean droplet behind Cloudflare for $24/month + an extra 25gb block…

The other problem is that one goes down, they all go down. A static website has absolutely no reason to go down.

It's all containerized. The only reason for it to go down is if DO or CF have an outage. Which is rare enough that it's not an issue for me.

Re: Static site hosting hurdles

#75

Post by ipaddr »

laundermaf wrote: post #61
esperent wrote: post #30

I switched from Vercel static site hosting, because I recently read an article here about how it's usually more economical to scale vertically instead of horizontally (i.e. use one big server for everything). Even though I'm only running a few services, I did the math and realized it's absolutely true. I can fit everything I'm running onto one DigitalOcean droplet behind Cloudflare for $24/month + an extra 25gb block…

The other problem is that one goes down, they all go down. A static website has absolutely no reason to go down.

But often does because the host, external lib or cloudfaire has an issue.

Re: Static site hosting hurdles

#76

Post by chubot »

bachmeier wrote: post #71
chubot wrote: post #64

Earlier quoted context omitted.

I prefer not to use free services because they're not sustainable, and they usually come with strings attached Remember I've been using this for 13 years, and if it keeps on working the same way, I'll use it for another 13 easily. (I've hosted multiple sites on it over the years) The current page claims it's $3.95 a month if you pay yearly: https://www.dreamhost.com/hosting/shared/ I thought mine was more like $8 but…

> I prefer not to use free services because they're not sustainable Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.

When I say "sustainable", I don't just mean that the company might not have enough money to keep its lights on

It's more that some product manager or VP will notice this free service and want to attach their strings to it.

Having worked in big tech, it happens very often. Google Groups is a famous example at Google (among many). It was way better 15 years ago, but it just wasn't "worth it" to keep the lights on in its current state, so it shuffled through a series of product managers/teams who wanted to "improve" it.

Microsoft has a long history of this as well. I feel like this is another generational thing -- people forgot what Microsoft used to be like, and how their free products turned hostile. So far Github is OK, but I'm sure glad there are alternatives.

I prefer to just pay money to a company that provides a service, and I hope they profit from that. That incentives should be aligned. So far with Dreamhost that has worked out exactly as expected.

If I had spent any time migrating to the latest and greatest thing in the last 13 years, that would have easily burned the money I have saved by using a free service.

e.g. I have hosted sites on other platforms that are now down and useless, as I'm sure many others here have.

Re: Static site hosting hurdles

#77

Post by chubot »

kej wrote: post #50
chubot wrote: post #35

Earlier quoted context omitted.

FWIW I also tried NearlyFreeSpeech, which is the top comment in the same thread I linked: https://news.ycombinator.com/item?id=29253277 I think it is good, and will solve people's static hosting problem. It's a server that you don't have to manage. It has a nice fast custom web interface. Except I didn't realize it was FreeBSD. That probably doesn't matter for most, but I'm used to Linux, so I like Dreamhost better.…

As a long time (but very light) Nearly Free Speech user who is also more used to Linux, I'm curious if you ran into specific problems because of them using FreeBSD, or if it was just the general feeling of things being slightly different than you're used to (which is totally a valid reason to prefer something else, I'm just wondering if it was more than that)?

I think a lot of it was the network file system issue I mentioned -- the shell felt slow, and I suspect it was because of a network disk. I can't be sure, but I think that is a significant difference between Dreamhost and NearlyFreeSpeech.

Also at that point I had used Dreamhost for ~10 years, so I was just more comfortable with it. I like how my files are in ~/oilshell.org and my logs are in ~/logs/oilshell.org. If I had started with NearlyFreeSpeech I'm sure it would have been fine

IIRC the reason I tried it was because I was looking for FastCGI support (i.e. non-PHP dynamic sites that you don't have to maintain a daemon for)

I don't quite remember, but I think they did have some FastCGI support, but it wasn't quite what I wanted, or maybe the Python version was different, etc. It looks like a great service, but I don't currently use it

Re: Static site hosting hurdles

#78

Post by Groxx »

chubot wrote: post #66
nine_k wrote: post #55

Earlier quoted context omitted.

Nothing's wrong, it just gives much more than needed to serve a static site! I like the idea to statically pre-generate entire HTTP responses, with all headers, and just serve a byte stream mindlessly once a URL is mapped. If TLS is handled by a separate proxy (that only does TLS termination), the "web server" becomes as trivial as it gets. Fast, simple, due to the simplicity probably bulletproof.

I don't really follow what you're saying It serves static sites. I upload my files with rsync, scp, or git, and they are served

There's still a "web server" in front of those files that speaks HTTP and delivers those files. An extremely simple one, but it still exists.

What they're proposing is cutting out the "speaks HTTP" part in favor of entirely pre-recorded responses. Whether you think that's feasible or not depends on where you draw the line in the sand, but it can certainly be easier to implement than nginx.

Re: Static site hosting hurdles

#79

Post by doodlesdev »

bitexploder wrote: post #28
decasia wrote: post #26

I guess everyone has their own solution to this. Here's mine: - Write some static html and one stylesheet - Pay DigitalOcean for the cheap plan - Run nginx + letsencrypt - Apply linux security updates promptly - Occasionally pay to renew the domain So yeah, that does take a little bit of (very simple) systems administration skills, and it's a recurring commitment. But there is no such thing as a successful but unmain…

Let the updates run automatically. Put certbot on a cron. Ride it until ubuntu LTS I am on dies. So easy. :)

You can also use Caddy in place of NGINX and let it handle Lets Encrypt for you :)

Re: Static site hosting hurdles

#80

Post by bathtub365 »

Groxx wrote: post #78
chubot wrote: post #66

Earlier quoted context omitted.

I don't really follow what you're saying It serves static sites. I upload my files with rsync, scp, or git, and they are served

There's still a "web server" in front of those files that speaks HTTP and delivers those files. An extremely simple one, but it still exists. What they're proposing is cutting out the "speaks HTTP" part in favor of entirely pre-recorded responses. Whether you think that's feasible or not depends on where you draw the line in the sand, but it can certainly be easier to implement than nginx.

Web servers exist already. Does what you’re describing exist?
Post reply on HN