Sobering, eye-opening, and encouraging in one swell foop. I am bookmarking & backing this page up because it coalesces many many issues that have been plaguing me with static site generation.
It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront.
But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitches this as an attempt to “standardize the hosting side of static sites”, which doesn’t pass muster for me. We’ve already standardized the hosting side of static sites by using the file system. Shifting to a new storage format besides “HTML on disk” doesn’t unify anything, nor does it seem desirable to have fewer options for serving content.
Competitive by what metric? My site lives more or less entirely within the AWS free tier. I think my total AWS bill is around $20/mo, and 80% of that is for the stupid number of domain names I’m hosting zones for.
Quick question: Why wouldn't I use my free tier registrar DNS? Are there really that man DNS queries serviced cause you pay based off the number of responses? Especially if they are stupid domains.
As far as I can tell, there’s only 2 upsides I’m getting by using AWS as a registrar:
1. I’m lazy, and I already manage a bunch of other stuff in AWS, so it’s convenient for me to have the domains in the same place
2. For some of the domains, I’m serving records that point to other AWS resources (like Cloudfront and S3). AWS’s Route53 has clever helper features when you’re pointing records at other AWS services).
Otherwise, you’re right that there’s plenty of registrars that’ll do perfectly solid DNS
The most familiar computer to young people, their smartphone, does everything to hide and abstract away the file system and even the fact that it's a computer.
When someone doesn't even realize a concept exists, it shouldn't come as a surprise they will struggle.
More cynicism is warranted here. "Platform companies" like Google and Apple love it when users fail to understand how their devices work, because they get locked-in to the plaftorms. This is the successful end result of a long campaign of deliberate miseducation of users.
I think people in the web development space will continue to understand this concept. People who are curious will learn how the internals work.
For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work.
Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess of “new directory” and “copy of copy of essay5.doc” I’m so thankful that most folks don’t have to deal with that anymore. They can use their computers instead of fighting them.
I’m apparently young enough to be targeted by this article so I’ll weigh in. We’re better off for it, files as a storage layer and/or format (meaning how routes on web servers are defined by the folder structure) suuucks. File semantics are annoying, complicated enough that nobody really gets them right, and broken at the margins. The concept of a virtual read head and seeking around files would never be invented today. File descriptors keeping random external magic state? What could go wrong? All but a tiny few file operations not being atomic — bleugh. See the stuff Ansible has to do just to get atomic copy. Permissions, attrs, xattrs, acls, and SELinux tags are a god damn mess. Locking is also a mess and filesystem dependent — sqlite doesn’t officially support NFS because of it. And with all that useless metadata we still don’t have a way of actually reliably specifying the format or encoding of files leading to garbage library after garbage library for guessing it. File paths being binary strings on Linux is a ridiculous tripwire, running out of inodes or open file handles is a leaky abstraction, links — hard and soft are a bandaid and make traversal stupid to reason about. Look at the dumb shit tar has to do to deal with it. Holding handles to deleted files is absolutely ass backwards and a pox on the people that made it necessary for updates to work. File rotation just shouldn’t be necessary. The application having to think about compression is the wrong layer. Whoever invented unix:abstract files committed a warcrime.
If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.
Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.
Unless you are an engineer working directly with code concerning file systems, you don't need to know any of that. Well, maybe file permissions, but most people don't need to deal even with that in their daily uses of computers.
Being able to understand where your data is located in a computer and knowing how to manipulate them makes a lot of subsequent data management easier. For one, a file system is independent of any given piece of software. You don't need to rely on your word processing program knowing where your documents are, you can just tell it where your document is. You don't need to wrangle with sending a picture from your Photos program to your email program, you can tell your Photos program where to save the picture and you can just tell your email program where your picture is.
And did I say picture? Is it a JPEG? PNG? GIF? An abstraction of the file system won't tell me, but if I go look in the file system I can immediately tell what the picture is, and where it is too.
And like I just alluded to, you get to decide where the files reside too. Your Photos program might stuff all 6000 of your pictures under "C:\Program Files\VendorMcVendorface\Photos\userdata", and sure, that works, but that's nonsense. You could sort everything exactly how you want it where you want it. "C:\Photos\2006\Yosemite" for just all the pictures you took on a trip to Yosemite National Park in 2006, for example.
Admittedly, it's a feat that file systems have been successfully abstracted away for Joe Average, but not knowing how to navigate and use file systems is going to bite you in your arse when something inevitably comes around demanding you do it.
Understanding file systems is one of those bits of knowledge and wisdom in life you can do without, until you can't. And by then, you don't have time to call for a time out and get a crash course on it.
In fairness to younger generations, I can never figure out how to use file choosers in modern operating systems or in crap like google drive.
It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
(Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.)
It's like some UI designer didn't understand folders, then somehow forced their brain damaged mental model of them on the rest of the population. After that, for some reason I will never understand, the rest of the industry copied the design.
(I've worked on filesystem implementations, tested for POSIX compliance, debugged insane customer issues, etc, etc. I know how directories work...)
> It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.
> Worth noting that the incoming younger generations can't and don't into file systems. [...] We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[the author here] The article is not about misunderstanding file-systems.
As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.
Not that I'm interested in arguing against your intent, but the second and third paragraphs clearly lay out the article is about the younger generations not knowing what a file system is.
I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.
If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.
Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.
Just using the file system is inadequate for some reasons that TFA mentions. For instance, returning gzip or Brotli compressed versions of resources, or returning HTTP 301/302 redirects for certain requests.
Also if you use CloudFront be aware you'll be paying for bandwidth, so if one of your pieces goes viral (or you're just a popular writer) the cost can be surprisingly high (over $50/mo).
Pretty sure you can stay in free tier without a CC on file though? So assume they’d just deactivate your services if you breach free tier resources for the month..(?)
But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.
> [...] the article somehow concludes that bringing your own server with the right configuration is not an option.
[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)
However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.
Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.
But do you really need different headers for different resources for a static site? I can imagine a distinct "downloads" folder maybe, but not much more.
I agree -- the OP said space for all the separate HTTP response variations might be an issue, and "With a smart enough storage format all of these could be solved".
I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.
I think these issues only exist if you decided to host the site yourself, I did and currently optimizing Caddy settings, but kawipiko surely seems interesting, however I use caddy as a reverse proxy too, so I can't switch.
If you just to chose to use Cloudflare Pages you will get the best settings, and performance by default, its effortless.
I self host because Cloudflare already has enough control on the internet, it serves more than 20% of the web!
Ok so let's make a UI that asks for your credit card and which host you want... This has nothing to do with the web servers IMO. Even if we give people the configuration done there will still be other issues. It has to be as easy as pressing one "go online" button, really.
I've never even worked with lambda and s3, and CF workers and R2 took like 20 minutes for me to learn and set up.
I don't know how they made it so incredibly easy to learn and get going compared to AWS, but every time I try to figure out how to do AWS I get confused and get put off.
aws has too many knobs, presumably to satisfy the union of the needs of all the enterprise customers. that said, lambda+s3+dynamodb+ec2 are pretty good once you tape over all the knobs that aren't needed. i work with them like this[1].
these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match.
Just because there are a lot of options, doesn't make something complicated. Hosting a static site - arguably the simplest kind of site - could be easily done with any of the options listed and derided at the start of the article.
I used to use Amazon but something broke somewhere and I haven' fixed it. Netlify was very low effort on my part. However I really like the idea of this approach as it helps feed into owning your own data. So I may have another go using this.
How do you get your content into Netlify? They push the CI/CD angle pretty hard (sometimes to the exclusion of other things; e.g. bugs in the CLI that break things if you aren't on their expected/happy path) and the fetishization of GitHub-integrated CI/CD leads to stuff that is about as complex as the traditional undesirable IT overhead.
My static website is in a private GitHub repo. I simply push to that.
Because my site is not statically generated there’s no real complexity here? When I’m working on it locally I simply open a .html file from my local drive in a browser. When I’m done I push to GitHub and Netlify updates in seconds.
> the cloud operator, given that all of the above choices are self-hosted (or at least require some system administration skills), would immediately go for a hosted solution like CloudFlare Pages, Netlify, Vercel, or one of the source code hosting sites that also have static site hosting solutions like SourceHut pages or GitHub pages;
i think of myself as a graybeard (in the article's parlance; i find the term exclusionary) and i use cloudflare in front of github pages. every year i've spent as this craft has seen me accumulate more than a year's worth of new things i'd like to program or learn, 30 years in the list is very long. spending my time and energy doing IT for a static web site is a major waste
Yeah exactly. As I am saying to another person in this comment section here: it's not about if I can do do the thing in HTML+CSS and upload it. Of course I can. But it's extremely low in my list of priorities. I prefer to write a Markdown article, run just one command, preview locally and if happy, do a `git push` -- the rest is being handled for me.
Way too many people wear their meaningless manual busywork as a badge of honor.
No time or patience for that crap. These are the things that the computers were invented to do. Let them, they do it better. You are a creative force, use your energy on creative endeavours, not on pointless BS.
I, like you, have no less than 500 things in my mental (and partially written) backlog to "check one day". I want to eventually get to that point, not to write HTML.
There's also HTTP HEAD requests, and "304 Not Changed" that you need to take care of. This is what makes static site download look instantaneous. There's more of such optimizations.
With all these I find it better to stick with old Apache or similar service for speed, rather than a simpler service that only takes care of GET.
If one has the pre-generated response for a "simple" `GET` request (one that doesn't use conditional headers, ranges, or other advanced HTTP features), then a server could easily generate proper responses (based on that simple response) to any such complex requests. For example:
* `HEAD` is just taking the `GET` response and replying with just the headers (no body);
* if the pre-generated `GET` response contains an `ETag` header, then the server could easily handle an `If-Match` and `If-None-Match`; (else, such a static server implementation could fallback for each resource with a temporary generated `ETag` that is obtained by hashing the path of the resource and some random token generated when the server was started;)
* if the pre-generated `GET` response contains a `Last-Modified` header, then the server could easily handle `If-Modifiend-Since` and other related conditional requests; (else, the server could just consider that all resources have the `Last-Modified` header equal to the moment the server was started;)
* if the client requests a range of that resource, the server could easily respond with a slice of the stored `GET` response;
In fact, what I describe here is nothing out of the ordinary, all caching proxies do exactly this: they store the "simple" `GET` response, and then they derive all other responses based on that.
Last month I paid $1 for route53, 12 cents for S3. and am hosting my https site which I create with publii. Works fine. Took a little time to set up, but now it is just a button push to update the site. Great for my personal blog and phtot gallery.
I pay 80 cents for the same as you. I only have 1 domain on route53. But I do also have a Lambda and API_GW mixed in there that get's infrequent to zero use.
Uh what's wrong with shared hosting? I use Dreamhost but there are dozens of others. It costs less than $10/month and I've used it since 2009.
I think the industry (or part of a generation of programmers) somehow collectively forgot that it exists. I don't see any mention of it in the article -- it solves the problem exactly. It easily serves and survives all the spikes from Hacker News that my site gets.
Shared hosting is a Linux box with a web server that someone ELSE manages. You get an SSH login, and you can use git and rsync.
It's associated with PHP hosting, but it is perfect for static sites.
Their custom panel with deep integrations are phenomenal for side projects or small businesses. In under a minute you can have your web server, SSL cert, database and more all setup and working - and you don’t have to manage any of it.
I wish more companies offered their level of managed services.
Is there anything really wrong with a CPanel host with FTP upload?
Namecheap, Dreamhost, GoDaddy even (well maybe not them lol). There are a billion shared hosts everywhere and CPanel really isn't hard to use for HTTPS enabling or getting FTP locations to work with.
------
Bonus points: shove a random .php file in there and it probably will work if you need just a little bit of dynamic content.
>Is there anything really wrong with a CPanel host with FTP upload?
Nothing, other than that it's not cool with the kids because it's the grandpa's way of being a webmaster.
Personally, being an old school grump, I'll choose FTP upload over Git nonsense any day of the week because why in the nine seas of the seven hells do I need to sign up for Github, upload all my crap there, download-install and run a Git daemon, feed it my Github login credentials, let the daemon download and sync/compile/whatever the code I have there, and then probably run the whole contraption through sixty dozen frameworks of JavaShit to have a website?
I'll just fire up Filezilla or whatever is the trendy FTP client nowadays, punch in my login creds, upload my crap that I wrote up in Notepad++, maybe have some fun with PHP because I'm old school, and be done with it. :V
You over-focus on what's cool or fashionable. For many of us that's absolutely not the reason to go (or not to go) with a platform.
GIT is extremely useful for versioning. I want that. If I make a dumb mistake I want to have a diff that I've fixed a typo / grammar / added more links etc.
You neither need to use GitHub nor give your GitHub credentials to anything. You can just make a public repo and have it cloned / pulled-from by literally anyone interested -- why would anyone clone your public blog repo and re-host it? You can use sr.ht, Codeberg or just host your own GIT -- it's not that hard if you're into it (I am not).
Your way of doing it is fine but let's not pretend that everyone else is following fashion or coolness. That's very rarely true. There's a list of very good reasons to use a public GIT repo + Netlify + use a static site generator on your own machine to only produce a directory of HTML+CSS files.
Generally speaking, I subscribe to the philosophy of KISS.
For a multi-user environment where a dozen people could be accessing the same file at any given time, yeah some sort of version control system will probably make everyone's life easier.
For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
This isn't to say your way isn't wrong /for you/, of course. Whatever floats your boat. For me, it's all just unnecessary complexity that will invite in all sorts of gremlins to waste my time.
> For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
Hard disagree. As I said above and you ignored it (no clue why): I want to have a history of my static website.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
I can and I don't want to. Markdown is tons easier, you write out an article, execute one command, push the updated HTML+CSS files to GIT and you're done. If we're talking about simplicity let's not ignore that scenario because it really is quite simple.
I got a backlog of 30 things to work on and 500+ to check out "one day when I have the time". Going back to hand-crafting HTML is likely at spot #1784 in my brain. It's a meaningless paperwork that can and must be outsourced to computers.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
At a minimum, static site generators create indexes, table-of-contents, tags, sorts by date, and other such features.
Pretty much no one writes good, raw, HTML these days. Documentation is written Sphinx, texinfo, docbook, and many other formats. Why? Because compiling chapters (or pages) together through static analysis is a very useful pattern for writing.
HTML is just an output pattern. Your actual words should be in a document generator at a minimum.
My website [1] is good raw (X)HTML [2]. It's just a couple of pages though, nothing fancy. If I was keeping a blog or something, I would definitely go for an SSG.
Git for static site versioning? Why not just copy the HTML into a new folder? Takes seconds. Zero complexity. Gets backed up with your regular system backups.
Git is great for collaborative or complex projects, but for a static site, you're using a freight train to bring a single tomato to market.
Lots of us old school grumps still running things the old fashioned way for many years, serving millions of requests without issue, customers happy, and with a deployment pipeline anyone can understand :)
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. Also I feel like they are using some kind of slower NFS disk, whereas Dreamhost feels like a bare metal disk mostly.
-----
I was trying to find another thread here, where someone remarked that "shared hosting" got a bad reputation in the early days due to janky control panels and bad/aggressive marketing.
Also a lot of the companies seem to have gotten acquired in the early 2000's, i.e. they changed hands a lot.
But again I've been using Dreamhost since 2009 and it's been great. No complaints except the typical thing everyone does of raising the domain name pricing after a year (the advertised price is the "first year discount").
They have not raised the hosting fees. (You might save $3 per year using a domain name purchased elsewhere, but that doesn't seem worth the hassle to me.)
So I thought there were many other shared hosting companies, but maybe not? Maybe they all got caught up in acquisitions and then the service declined? (That's exactly what's going to happen with the free cloud services you're all using now BTW, so that's why I stick with something older and proven.)
I have used 1and1 in the early 2000's, but I remember it being very janky and weird, and Dreamhost is a lot better technically. They seem to have more competent system administration.
Honestly I wonder if Dreamhost is more unique now than it used to be? I thought of it as "commodity shared hosting" -- i.e. a Linux OS and a web server. But I think that actually being able to manage that competently is a dying art :-/
Other threads I bookmarked while looking for shared hosting that supports FastCGI (dynamic sites, not static, and not PHP!):
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
Please check https://elest.io
You can deploy WordPress, Ghost, Magento and 185 fully managed software. You get a dedicated VM with stellar performances, SSL, smtp, security, borg ans S3 backups, monitoring, logs and full root access even if it's managed.
We also support CI/CD pipelines.
I've also been a Dreamhost customer for a long time. Note that Dreamhost's $10/mo is for I-don't-know-exactly number of domains. If you own a domain name you can add it in their dashboard, point it to their name servers, and you're up and running. Their services includes e-mail which means avoiding the perils of fully self-hosting.
While you could save a few dollars renting a VPS, it's only cheaper if your time is worth nothing. If you're just going to do static hosting I've found it to be a good deal.
You can register your domains anywhere and point them at Dreamhost. I don't recall any fees for setting up a new domain with them so long as you already own it.
Another DreamHost fan here. I host dozens of hybrid sites on both the shared hosting and VPS and the service is great. My setup is pretty simple, a Perl-based SSG which generates static HTML on-demand if it happens to be missing from the tree.
I've had a few minor issues over the years, often self-inflicted, and whenever I use the support panel, I get a helpful human response within an couple of hours, usually with a resolution. If I have to respond, I can respond to the email by email!
It's both, and can run in several different modes.
In dynamic mode, you are correct that the HTML files act as a cache.
In static mode, the on-demand layer (and any related hooks in the web server) are turned off, with all the pages being pre-generated.
There is also a hybrid mode, where the access log (and content store) is scraped for updates and they're integrated into the static HTML on a schedule.
Each of these has its own advantages and drawbacks in terms of security, accessibility, performance, and convenience.
Yep. Been on Dreamhost since 2004. Just create the html file and sftp it using FileZilla. Setting up a domain is just a few clicks on their admin site. PHP + MySQL works perfectly. All for $10/month.
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.
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.
[the author here] Well, the article does point in the last section "Putting it in practice" to my own implementation <https://github.com/volution/kawipiko>. :)
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)
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.
I don't disagree with you but you can't use Google to support your argument. They have to be the worst player out there when it comes to supporting free services over the long-term. You're so much safer with Github's free tier, there's no comparison.
> I prefer not to use free services because they're not sustainable, and they usually come with strings attached
When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for.
So I hosted my websites with Nearly Free Speech (NFSN), where hosting is actually by what you consume. For small static sites, you could get a lot more mileage with NFSN and still not pay more than a couple of dollars a month. It’s a lot cheaper than your Dreamhost plan, and is truly sustainable because NFSN gets very close to recovering its costs plus a little more to sustain, grow and become better. NFSN also doesn’t have tricks like referral programs and other special discounts, unlike Dreamhost (talking from what I’ve seen about Dreamhost in the past).
The major downside is it doesn’t have cPanel and fancy application installers. But that shouldn’t be an issue for people who would use scp to setup web pages on a host.
This had me wondering when GitHub Pages was actually introduced; earliest sign I can find is a blog post [0] from December 2008, so that's almost 14 years ago.
It’s static hosting. If they change their terms, it couldn’t be any easier to switch. I switched most of my Netlify sites to CloudFlare Pages in like 10 clicks each. The whole point of having a static file is that they’re super easy to manage.
Worst case scenario you pay a few cents to host on S3 and stick any free-range CDN on it.
I categorically refuse to use any non-static hosting for static content. Your shared hosting runs code and can be compromised, especially if you host multiple software/sites on it.
Your domain alone is going to cost about half that, and much more for fancy domains. Depending on whether you need a site mail contact (sometimes required for abuse@yoursite.com) and certificate (for any ecommerce site), we're talking about at least twice that. We do talk about serious hosting, do we?
.com is around ~10$/year, email server is included in practically all shared hosting, and basically every shared hosting offers free TLS via Let's Encrypt (or some other provider.)
There are still some limits to these (for example Netlify limits the bandwidth you can use each month), but yeah, for most practical purposes the free tier should do just fine.
On a side note, I'm wondering if one can host one site simultaneously on e. g. Netlify and Vercel and load-balance those (for example, with round-robin DNS) to stay within free limits for longer.
There are web hosting plans at less than 3$/month.
There are also community hosting networks offering different kind of hosting services for a small sum / year. Here is an example of such a network mostly france based but I am sure there are same kind of initiatives all over the world:
https://www.chatons.org
Sure, that is a lot for hosting a single static site. But, that $10 essentially gives you unlimited sites, unlimited email hosting, SSL cert management, lots of storage, unlimited network, and much more…
It's never unlimited, the terms and conditions for shared hosting are specifically designed to prohibit use cases (ex. file storage not connected with a website) that generate excessive usage.
And if you somehow find a loophole you'll quickly become persona non grata.
Ten dollars sounds a bit expensive for shared hosting? I have been happy with Hawkhost for the last 10 years, which starts their shared hosting options at $2.99/month. That is 10 GB storage, unlimited bandwidth, host as many domains as you want, SSH access, choose between servers in EU or America. I even use it for some email addresses.
I have great respect for the folks keeping this stable and working for decades for such a low price!
[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)
Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.
It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.
The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:
* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)
* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.
Most people don't need all that complexity and configuration options, especially if you just want it to work.
Asset minification can be done locally, besides the ominous gatekeepers don't give a fuck. I've got a static website with lots of files, just HTML and CSS, not even minified I think, and a dozen lines of JS, and it's a solid 100/100 on Page Speed Insights.
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough
Shared hosting is basically where somebody configures and runs Apache or Nginx for you ... they know how to do this, and it definitely works!
> I don't think it's still a common choice for today.
Not true at all. About 37% of the web hosting market is shared hosting. Just do a simple web search for the size of the web hosting services market to find this information. It's one of the 3 most common choices today – and it's always been that way.
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 unmaintained web site. Even if you don't have to maintain the infrastructure, you have to maintain the content. So I don't mind the occasional maintenance tasks. They keep me in touch with linux systems administration in a good way.
It's cool to write your own web server software, I guess. But serving static html is pretty much a solved problem. I felt like the OP was inventing problems with it that don't really exist in practice.
I hadn’t really touched caddy in a while. For a static site I may just do that if my cron script ever falls over. I was also feeling hipster and wanted to play with Justine’s redbean. It is sort of appealing to just drop a binary off somewhere and be done with it, but like `apt install nginx` is also trivial as a user :)
I'm using Caddy with Docker labels auto-configuration.
It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works.
The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy.
> Each caddy docker proxy instance can be executed in one of the following modes.
> Server
> Acts as a proxy to your Docker resources. The server starts without any configuration, and will not serve anything until it is configured by a "controller".
> Server instances doesn't need access to Docker host socket and you can run it in manager or worker nodes.
This can be mitigated by running in the Controller mode
I'd be nice to run a self-hosted site from a home server. Currently paying a third party for a static site, but space is so limited. Storage space isn't that expensive, until you have to pay monthly for it. Mostly just want to host my own pictures.
Would really like a hands on workshop to learn to do it (how to get a static IP, setup everything correctly, how to use https).
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 storage for $2.5/month + $5/month for backblaze backups.
Everything being: a bunch of static sites, Keycloak Auth, Rocket.Chat, Odoo business management software, Nginx Proxy Manager, Outline (self hosted Notion), Docker, Portainer, Cockpit, Listmonk.
Static sites are free actually, besides storage. You can just add a location directive pointing to the folder in Nginx Proxy Manager and it'll serve the files for you.
The biggest memory hog is Keycloak which is a Java app so it uses 700mb of ram.
But in any case I have set up an entire small business software suite with a hosting cost of $31.5 and I can host unlimited static sites with no additional cost.
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.
There's a bit of risk to having all your eggs in one basket.
One is security, although containers mitigate that. Another is resource allocation. If one piece of software hogs all the resources, others will suffer.
Personally I split things just because it matches my mental model. My personal website runs somewhere. My professional website runs somewhere else. My home server gets its own dedicated hardware.
The limits are actually pretty darn extreme for CF Pages — no bandwidth limits, 20000 files, and 500 deployments per day.
It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.
The article is right in that setting up a server for any kind of hosting is not a simple task. There are no "good defaults" or "templates" easily embeddable/extendible for your specific use-case.
fasthttp doesn't implement HTTP/1 correctly, and doesn't implement HTTP/2 at all. It's not an appropriate choice for a general purpose tool or library. The code is also not correctly formatted. Strong negative signals.
Could you point to an issue describe such an improper behavior?
> doesn't implement HTTP/2 at all
Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144>
And I'll quote here what I've said there:
> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.
Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.
Quick but important note: for those who don't know already, Volution sells a square space-esque managed site builder with hosting, which means this post does have a minor conflict of interest (although these days I guess it's called content marketing). Haven't seen it mentioned yet in the comments.
[the author here] Where do I sell a "square space-esque managed site builder with hosting"? I need to get on some of that revenue! :) :) :)
Under the name of "volution" I own the following:
* volution.ro -- where this article was posted, which contains no products or hosting services, or even advertising to anything; (it does contain links to my GitHub projects, all of which are purely open-source; and links to my business site bellow and to another project I'm working on but which has nothing to do with hosting;)
* volutico.eu -- which is a "under construction" page for my consulting firm;
* github.com/volution -- where there are a few more polished open-source projects, including <https://github.com/volution/kawipiko> which is an open-source implementation of the ideas described in this article;
So, either there this is a case of mistaken identity, or please point me in the right direction.
(Searching on the internet for `volution` it does yield some companies which have a similar name, but those have nothing in common with me.) :)
Ah, my apologies! This is the one I thought you were associated with; one letter makes a big difference: https://www.volusion.com/
I figured it was one of those "founder-has-a-blog-with-very-similar-name-to-capture-new-users" situations. Nothing wrong with it, just something I feel it's important to be aware of. Sorry for the mixup!
I am currently using GitLab to do my static site hosting for free using their pages feature. And I get to use my own domain name and have SSL/https support automatically.
182 comments
[ 2.9 ms ] story [ 219 ms ] threadWell done.
But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitches this as an attempt to “standardize the hosting side of static sites”, which doesn’t pass muster for me. We’ve already standardized the hosting side of static sites by using the file system. Shifting to a new storage format besides “HTML on disk” doesn’t unify anything, nor does it seem desirable to have fewer options for serving content.
https://neocities.org/supporter
1. I’m lazy, and I already manage a bunch of other stuff in AWS, so it’s convenient for me to have the domains in the same place
2. For some of the domains, I’m serving records that point to other AWS resources (like Cloudfront and S3). AWS’s Route53 has clever helper features when you’re pointing records at other AWS services).
Otherwise, you’re right that there’s plenty of registrars that’ll do perfectly solid DNS
Worth noting that the incoming younger generations can't and don't into file systems.[1]
Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point.
We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[1]: https://www.theverge.com/22684730/students-file-folder-direc...
The most familiar computer to young people, their smartphone, does everything to hide and abstract away the file system and even the fact that it's a computer.
When someone doesn't even realize a concept exists, it shouldn't come as a surprise they will struggle.
For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work.
Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess of “new directory” and “copy of copy of essay5.doc” I’m so thankful that most folks don’t have to deal with that anymore. They can use their computers instead of fighting them.
If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.
Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.
Being able to understand where your data is located in a computer and knowing how to manipulate them makes a lot of subsequent data management easier. For one, a file system is independent of any given piece of software. You don't need to rely on your word processing program knowing where your documents are, you can just tell it where your document is. You don't need to wrangle with sending a picture from your Photos program to your email program, you can tell your Photos program where to save the picture and you can just tell your email program where your picture is.
And did I say picture? Is it a JPEG? PNG? GIF? An abstraction of the file system won't tell me, but if I go look in the file system I can immediately tell what the picture is, and where it is too.
And like I just alluded to, you get to decide where the files reside too. Your Photos program might stuff all 6000 of your pictures under "C:\Program Files\VendorMcVendorface\Photos\userdata", and sure, that works, but that's nonsense. You could sort everything exactly how you want it where you want it. "C:\Photos\2006\Yosemite" for just all the pictures you took on a trip to Yosemite National Park in 2006, for example.
Admittedly, it's a feat that file systems have been successfully abstracted away for Joe Average, but not knowing how to navigate and use file systems is going to bite you in your arse when something inevitably comes around demanding you do it.
Understanding file systems is one of those bits of knowledge and wisdom in life you can do without, until you can't. And by then, you don't have time to call for a time out and get a crash course on it.
It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
(Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.)
It's like some UI designer didn't understand folders, then somehow forced their brain damaged mental model of them on the rest of the population. After that, for some reason I will never understand, the rest of the industry copied the design.
(I've worked on filesystem implementations, tested for POSIX compliance, debugged insane customer issues, etc, etc. I know how directories work...)
He probably didn't.
Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.
[the author here] The article is not about misunderstanding file-systems.
As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.
I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.
If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.
Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.
Also if you use CloudFront be aware you'll be paying for bandwidth, so if one of your pieces goes viral (or you're just a popular writer) the cost can be surprisingly high (over $50/mo).
But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.
[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)
However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.
Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.
I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.
If you just to chose to use Cloudflare Pages you will get the best settings, and performance by default, its effortless.
I self host because Cloudflare already has enough control on the internet, it serves more than 20% of the web!
https://w3techs.com/technologies/history_overview/web_server
I don't know how they made it so incredibly easy to learn and get going compared to AWS, but every time I try to figure out how to do AWS I get confused and get put off.
these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match.
1. https://github.com/nathants/libaws
I do skip the static generator part and go with artisinally hand crafted HTML/CSS/JS instead. It’s radically simpler and ultimately better imho.
Because my site is not statically generated there’s no real complexity here? When I’m working on it locally I simply open a .html file from my local drive in a browser. When I’m done I push to GitHub and Netlify updates in seconds.
i think of myself as a graybeard (in the article's parlance; i find the term exclusionary) and i use cloudflare in front of github pages. every year i've spent as this craft has seen me accumulate more than a year's worth of new things i'd like to program or learn, 30 years in the list is very long. spending my time and energy doing IT for a static web site is a major waste
Way too many people wear their meaningless manual busywork as a badge of honor.
No time or patience for that crap. These are the things that the computers were invented to do. Let them, they do it better. You are a creative force, use your energy on creative endeavours, not on pointless BS.
I, like you, have no less than 500 things in my mental (and partially written) backlog to "check one day". I want to eventually get to that point, not to write HTML.
With all these I find it better to stick with old Apache or similar service for speed, rather than a simpler service that only takes care of GET.
* `HEAD` is just taking the `GET` response and replying with just the headers (no body);
* if the pre-generated `GET` response contains an `ETag` header, then the server could easily handle an `If-Match` and `If-None-Match`; (else, such a static server implementation could fallback for each resource with a temporary generated `ETag` that is obtained by hashing the path of the resource and some random token generated when the server was started;)
* if the pre-generated `GET` response contains a `Last-Modified` header, then the server could easily handle `If-Modifiend-Since` and other related conditional requests; (else, the server could just consider that all resources have the `Last-Modified` header equal to the moment the server was started;)
* if the client requests a range of that resource, the server could easily respond with a slice of the stored `GET` response;
In fact, what I describe here is nothing out of the ordinary, all caching proxies do exactly this: they store the "simple" `GET` response, and then they derive all other responses based on that.
I think the industry (or part of a generation of programmers) somehow collectively forgot that it exists. I don't see any mention of it in the article -- it solves the problem exactly. It easily serves and survives all the spikes from Hacker News that my site gets.
Shared hosting is a Linux box with a web server that someone ELSE manages. You get an SSH login, and you can use git and rsync.
It's associated with PHP hosting, but it is perfect for static sites.
http://www.oilshell.org/blog/2021/12/backlog-assess.html#app...
Answer to the HN question: What's the fastest way to get a page on the web?
https://news.ycombinator.com/item?id=29254006
FWIW I also have a Linux VPS with nginx and a HTTPS certificate, but it's a pain. I much prefer using shared hosting for things I want to be reliable.
Their custom panel with deep integrations are phenomenal for side projects or small businesses. In under a minute you can have your web server, SSL cert, database and more all setup and working - and you don’t have to manage any of it.
I wish more companies offered their level of managed services.
(If anyone knows of others, I’d like to hear who)
Namecheap, Dreamhost, GoDaddy even (well maybe not them lol). There are a billion shared hosts everywhere and CPanel really isn't hard to use for HTTPS enabling or getting FTP locations to work with.
------
Bonus points: shove a random .php file in there and it probably will work if you need just a little bit of dynamic content.
I’ve been a customer since 2004
But I guess my overall point is that CPanel is way easier than anything the original poster / author wrote.
Nothing, other than that it's not cool with the kids because it's the grandpa's way of being a webmaster.
Personally, being an old school grump, I'll choose FTP upload over Git nonsense any day of the week because why in the nine seas of the seven hells do I need to sign up for Github, upload all my crap there, download-install and run a Git daemon, feed it my Github login credentials, let the daemon download and sync/compile/whatever the code I have there, and then probably run the whole contraption through sixty dozen frameworks of JavaShit to have a website?
I'll just fire up Filezilla or whatever is the trendy FTP client nowadays, punch in my login creds, upload my crap that I wrote up in Notepad++, maybe have some fun with PHP because I'm old school, and be done with it. :V
GIT is extremely useful for versioning. I want that. If I make a dumb mistake I want to have a diff that I've fixed a typo / grammar / added more links etc.
You neither need to use GitHub nor give your GitHub credentials to anything. You can just make a public repo and have it cloned / pulled-from by literally anyone interested -- why would anyone clone your public blog repo and re-host it? You can use sr.ht, Codeberg or just host your own GIT -- it's not that hard if you're into it (I am not).
Your way of doing it is fine but let's not pretend that everyone else is following fashion or coolness. That's very rarely true. There's a list of very good reasons to use a public GIT repo + Netlify + use a static site generator on your own machine to only produce a directory of HTML+CSS files.
For a multi-user environment where a dozen people could be accessing the same file at any given time, yeah some sort of version control system will probably make everyone's life easier.
For a single user environment as is likely the case for most static websites? Yeah, it's just needless complexity.
In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
This isn't to say your way isn't wrong /for you/, of course. Whatever floats your boat. For me, it's all just unnecessary complexity that will invite in all sorts of gremlins to waste my time.
Hard disagree. As I said above and you ignored it (no clue why): I want to have a history of my static website.
> In fact, you lost me at "static site generator". WTF? Just write the damn HTML and CSS yourself, it's static after all.
I can and I don't want to. Markdown is tons easier, you write out an article, execute one command, push the updated HTML+CSS files to GIT and you're done. If we're talking about simplicity let's not ignore that scenario because it really is quite simple.
I got a backlog of 30 things to work on and 500+ to check out "one day when I have the time". Going back to hand-crafting HTML is likely at spot #1784 in my brain. It's a meaningless paperwork that can and must be outsourced to computers.
At a minimum, static site generators create indexes, table-of-contents, tags, sorts by date, and other such features.
Pretty much no one writes good, raw, HTML these days. Documentation is written Sphinx, texinfo, docbook, and many other formats. Why? Because compiling chapters (or pages) together through static analysis is a very useful pattern for writing.
HTML is just an output pattern. Your actual words should be in a document generator at a minimum.
[1]: https://notpushk.in/
[2]: https://gitlab.com/notpushkin/notpushk.in
Nope. Anything I can have a machine generate for me is fancy if I have to write it by hand.
Git is great for collaborative or complex projects, but for a static site, you're using a freight train to bring a single tomato to market.
¯\_(ツ)_/¯
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. Also I feel like they are using some kind of slower NFS disk, whereas Dreamhost feels like a bare metal disk mostly.
-----
I was trying to find another thread here, where someone remarked that "shared hosting" got a bad reputation in the early days due to janky control panels and bad/aggressive marketing.
Also a lot of the companies seem to have gotten acquired in the early 2000's, i.e. they changed hands a lot.
But again I've been using Dreamhost since 2009 and it's been great. No complaints except the typical thing everyone does of raising the domain name pricing after a year (the advertised price is the "first year discount").
They have not raised the hosting fees. (You might save $3 per year using a domain name purchased elsewhere, but that doesn't seem worth the hassle to me.)
So I thought there were many other shared hosting companies, but maybe not? Maybe they all got caught up in acquisitions and then the service declined? (That's exactly what's going to happen with the free cloud services you're all using now BTW, so that's why I stick with something older and proven.)
I have used 1and1 in the early 2000's, but I remember it being very janky and weird, and Dreamhost is a lot better technically. They seem to have more competent system administration.
----
FWIW here is a thread with some competitors:
https://lobste.rs/s/jkutwc/recommendations_for_shared_hostin...
Honestly I wonder if Dreamhost is more unique now than it used to be? I thought of it as "commodity shared hosting" -- i.e. a Linux OS and a web server. But I think that actually being able to manage that competently is a dying art :-/
Other threads I bookmarked while looking for shared hosting that supports FastCGI (dynamic sites, not static, and not PHP!):
bluehost: https://www.bluehost.com/help/article/fastcgi-for-php
hostgator: https://www.hostgator.com/help/article/does-hostgator-suppor...
I'd be interested to know if those companies are comparable to dreamhost!
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
You just connect your git repo and tell it what command to run to build your site and where the html output is
Disclaimer: I work there ;)
While you could save a few dollars renting a VPS, it's only cheaper if your time is worth nothing. If you're just going to do static hosting I've found it to be a good deal.
But the hosting is a flat fee at less than $10/month. (edit: just checked, actually I pay yearly for a discount.)
So I find that to be pretty nice, because I have had 5 domains at one point. And now I have 3 or so.
But I always keep the same hosting account. It works well in practice.
I've had a few minor issues over the years, often self-inflicted, and whenever I use the support panel, I get a helpful human response within an couple of hours, usually with a resolution. If I have to respond, I can respond to the email by email!
All in all, can't praise DreamHost enough.
Just wish they used newer hardware than they do on their VPS & Dedicated offering.
In dynamic mode, you are correct that the HTML files act as a cache.
In static mode, the on-demand layer (and any related hooks in the web server) are turned off, with all the pages being pre-generated.
There is also a hybrid mode, where the access log (and content store) is scraped for updates and they're integrated into the static HTML on a schedule.
Each of these has its own advantages and drawbacks in terms of security, accessibility, performance, and convenience.
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.
It serves static sites. I upload my files with rsync, scp, or git, and they are served
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.
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.
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 honestly don't remember. It's a fair price for steady service IMO
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.
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.
When I checked Dreamhost several years ago, I found that it was also an oversold service that relied on most customers using way less than the promised capacity. This doesn’t mean that it’s bad at hosting websites, but it’s not something I wanted to pay for.
So I hosted my websites with Nearly Free Speech (NFSN), where hosting is actually by what you consume. For small static sites, you could get a lot more mileage with NFSN and still not pay more than a couple of dollars a month. It’s a lot cheaper than your Dreamhost plan, and is truly sustainable because NFSN gets very close to recovering its costs plus a little more to sustain, grow and become better. NFSN also doesn’t have tricks like referral programs and other special discounts, unlike Dreamhost (talking from what I’ve seen about Dreamhost in the past).
The major downside is it doesn’t have cPanel and fancy application installers. But that shouldn’t be an issue for people who would use scp to setup web pages on a host.
My point was that shared hosting exists, is good, and is the right solution to this problem. My point was not that you should use Dreamhost :)
I tried NearlyFreeSpeech a few years ago; some sibling comments describe my experiences
[0] https://github.blog/2008-12-18-github-pages/
Worst case scenario you pay a few cents to host on S3 and stick any free-range CDN on it.
I categorically refuse to use any non-static hosting for static content. Your shared hosting runs code and can be compromised, especially if you host multiple software/sites on it.
.com is around ~10$/year, email server is included in practically all shared hosting, and basically every shared hosting offers free TLS via Let's Encrypt (or some other provider.)
On a side note, I'm wondering if one can host one site simultaneously on e. g. Netlify and Vercel and load-balance those (for example, with round-robin DNS) to stay within free limits for longer.
There are also community hosting networks offering different kind of hosting services for a small sum / year. Here is an example of such a network mostly france based but I am sure there are same kind of initiatives all over the world: https://www.chatons.org
And if you somehow find a loophole you'll quickly become persona non grata.
As the saying goes, TANSTAAFL.
I have great respect for the folks keeping this stable and working for decades for such a low price!
Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.
It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.
The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:
* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)
* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;
The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.
Most people don't need all that complexity and configuration options, especially if you just want it to work.
Asset minification can be done locally, besides the ominous gatekeepers don't give a fuck. I've got a static website with lots of files, just HTML and CSS, not even minified I think, and a dozen lines of JS, and it's a solid 100/100 on Page Speed Insights.
Link headers? There's a HTML tag for that and it's fast enough: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types...
You're just bloating everything up.
Shared hosting is basically where somebody configures and runs Apache or Nginx for you ... they know how to do this, and it definitely works!
Not true at all. About 37% of the web hosting market is shared hosting. Just do a simple web search for the size of the web hosting services market to find this information. It's one of the 3 most common choices today – and it's always been that way.
No mention of neocities or shared/managed hosts (Namecheap or even GoDaddy?)
I mean, I know we nerds look down upon GoDaddy and other such sites, but it's cheaper than setting up a VPS and good enough for any static site.
- 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 unmaintained web site. Even if you don't have to maintain the infrastructure, you have to maintain the content. So I don't mind the occasional maintenance tasks. They keep me in touch with linux systems administration in a good way.
It's cool to write your own web server software, I guess. But serving static html is pretty much a solved problem. I felt like the OP was inventing problems with it that don't really exist in practice.
When I was self-hosting on a DigitalOcean droplet, I was using Caddy instead of nginx, which handled letsencrypt for me, so that was nice.
[0]: https://www.digitalocean.com/pricing/app-platform
It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works.
The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy.
[0] https://github.com/lucaslorentz/caddy-docker-proxy
> Server
> Acts as a proxy to your Docker resources. The server starts without any configuration, and will not serve anything until it is configured by a "controller".
> Server instances doesn't need access to Docker host socket and you can run it in manager or worker nodes.
This can be mitigated by running in the Controller mode
Would really like a hands on workshop to learn to do it (how to get a static IP, setup everything correctly, how to use https).
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 storage for $2.5/month + $5/month for backblaze backups.
Everything being: a bunch of static sites, Keycloak Auth, Rocket.Chat, Odoo business management software, Nginx Proxy Manager, Outline (self hosted Notion), Docker, Portainer, Cockpit, Listmonk.
Static sites are free actually, besides storage. You can just add a location directive pointing to the folder in Nginx Proxy Manager and it'll serve the files for you.
The biggest memory hog is Keycloak which is a Java app so it uses 700mb of ram.
But in any case I have set up an entire small business software suite with a hosting cost of $31.5 and I can host unlimited static sites with no additional cost.
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.
One is security, although containers mitigate that. Another is resource allocation. If one piece of software hogs all the resources, others will suffer.
Personally I split things just because it matches my mental model. My personal website runs somewhere. My professional website runs somewhere else. My home server gets its own dedicated hardware.
It's mind-boggling for me to read the comment section with people paying (and recommending!) anything above 0$/mo for static page hosting, because most likely GitHub / CF Pages can handle more requests than that and requires zero maintenance.
https://pages.github.com/
Could you point to an issue describe such an improper behavior?
> doesn't implement HTTP/2 at all
Or HTTP/3; and most likely it won't implement HTTP/4 (after the HTTP/3 fashion dies out). There is an issue about this on `fasthttp`'s repository: <https://github.com/valyala/fasthttp/issues/144>
And I'll quote here what I've said there:
> Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.
Thus if one needs HTTP/2 or HTTP/3 in order to reap their performance benefits, then using a CDN that actually supports these is the best approach.
Under the name of "volution" I own the following:
* volution.ro -- where this article was posted, which contains no products or hosting services, or even advertising to anything; (it does contain links to my GitHub projects, all of which are purely open-source; and links to my business site bellow and to another project I'm working on but which has nothing to do with hosting;)
* volutico.eu -- which is a "under construction" page for my consulting firm;
* github.com/volution -- where there are a few more polished open-source projects, including <https://github.com/volution/kawipiko> which is an open-source implementation of the ideas described in this article;
So, either there this is a case of mistaken identity, or please point me in the right direction.
(Searching on the internet for `volution` it does yield some companies which have a similar name, but those have nothing in common with me.) :)
I figured it was one of those "founder-has-a-blog-with-very-similar-name-to-capture-new-users" situations. Nothing wrong with it, just something I feel it's important to be aware of. Sorry for the mixup!
I use:
- VuePress
- Amazon S3
- Amazon Certificate Manager
- Amazon CloudFront
- Amazon Route53
For deployment:
- CircleCI
- s3deploy
It's a super simple (and cheap) setup. Just push a commit and the site gets updated.