91–100 of 183 posts
Strange that a pretty common way to serve static sites is not mentioned: Multi-stage Docker builds [e.g. 1] an nginx-alpine image in Gitlab CI, that is automatically deployed to Kubernetes/a Docker host somewhere. Add the Let's Encrypt Container for automatic SSL. [1]: https://github.com/lewish/asciiflow/blob/fd0f72714cd307cbb02...
I highly doubt this is a common approach!
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…
I used to do something similar, but DigitalOcean App Platform's $0/month "starter" plan[0] hosts a static site for even less effort. 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.
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 pitch…
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).
Earlier quoted context omitted.
>We’ve already standardized the hosting side of static sites by using the file system. 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]: h…
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 tod…
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 costs me about 1 dollar a month (never more than 2 dollars) to host my website. 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.
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.
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'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.
* `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.
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.
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.) :)
No, you don't need a CDN for your lightweight static site. nginx and your home fiber gigabit connection will do _JUST_FINE_ (tm), even when slashdotted or getting on frontpage at HN.
Also, just drop the generators and write your html already.. Sure, it's fun to learn a new toy, but in end, any abstraction between your content and the HTML being served is just another link in the chain of things that can break.
Organize your HTML files well, use minimal styling and it becomes quite managable, you literally don't have a technology stack.. just dump the files on ANYTHING IN THE UNIVERSE that has a webserver and a file system, and you're good to go.