[HN Gopher] Generate static sites from Markdown files with Caddy...
       ___________________________________________________________________
        
       Generate static sites from Markdown files with Caddy (2018)
        
       Author : indigodaddy
       Score  : 95 points
       Date   : 2022-01-31 06:39 UTC (16 hours ago)
        
 (HTM) web link (blog.thomaspuppe.de)
 (TXT) w3m dump (blog.thomaspuppe.de)
        
       | ttty wrote:
       | Caddy it's the best thing ever. Having SSL out of the box it's
       | amazing. I tried ngnix etc and was a pain.
       | 
       | I can have a dedicated server and host a ton of stuff with docker
       | and use caddy to direct to each domain. I know nothing new, but
       | config is easy compared to rest. And again, I can't stress enough
       | how easy is to setup the SSL.
       | 
       | I'm going to donate some money because it really saved me a ton
       | of time.
       | 
       | For static files the best setup I think it's cloudflare workers
       | with kv and fallback on s3 bucket for huge files. S3 is much
       | cheaper compared to kv storage. (Backblaze + cloudflare bandwidth
       | it's also free. Caveat: if you host non website stuff like 3d
       | assets or raw images you might be banned by cloudflare)
       | 
       | I'm hosting many websites for clients with this setup and it's
       | very very reliable and can reach around 99 on Google page speed.
        
       | d12bb wrote:
       | I really like the Caddyfile and template syntax. Is where a way
       | to use this just to generate static HTML, without the server
       | part? I kind of want to stick with OpenBSDs plain old httpd as it
       | comes ootb and fullfills basically all the needs I have quite
       | fine.
       | 
       | Currently, I do all my HTML manually. I looked into static site
       | generators recently but didn't really like anything I've seen,
       | from Jekyll/Hugo to smaller projects like blogc...
        
         | francislavoie wrote:
         | You could use Gomplate: https://docs.gomplate.ca/
        
       | solarkraft wrote:
       | I haven't used Caddy for this use case, but as a simple proxy and
       | file server it's just great. IMO it's largely what Traefik
       | promises but fails to keep. An actual production Caddy
       | configuration with HTTPS set up, web sockets and everything fits
       | on a single line (or 3 if you want multiple hosts).
       | 
       | I can see myself checking this out (but for v2, of course). It
       | looks to be just as nice in this area as in the others.
       | 
       | More software should strive to be this user friendly.
        
       | ihateolives wrote:
       | Caddy is getting more and more interesting every day. I've been
       | long time Apache user since 1999 or something and I can (mostly)
       | bend its configuration to my liking to do what I need so I've sat
       | out this whole Nginx brouhaha because for my use cases it
       | provides close to zero added value.
       | 
       | But Caddy just might've convinced me to install it on my server
       | for pet projects and giving it a test drive.
        
         | capableweb wrote:
         | I've used all three of those for both hobby and professional
         | services deployed to production (going apache -> nginx ->
         | caddy). The only major difference is the configuration syntax,
         | that has gotten easier and easier moving from them.
         | 
         | What difference do you see between apache and caddy that makes
         | the move more worth it compared to apache and nginx? I guess
         | the added value is much more going from apache to caddy but not
         | apache to nginx, what added value is that for you?
        
       | 28304283409234 wrote:
       | Note: article hails from 2018.
        
       | sdevonoes wrote:
       | Caddy looks great. I'm used to:
       | 
       | 1. generate html from markdown 2. copy the generated html to
       | /var/www 3. Let nginx serve (and cache) it
       | 
       | Would caddy fulfil these requirements as well? Is it as
       | performant as nginx?
        
         | kalev wrote:
         | Yes, this would work with Caddy without you needing to generate
         | the markdown yourself or copy the generated html to /var/www.
         | You simply edit the .md files and Caddy automatically generates
         | the HTML on the fly. I don't have any benchmarks compared to
         | nginx but I'm using Caddy on multiple personal projects and I
         | don't have any complaints about Caddy's performance.
        
           | thamer wrote:
           | Does Caddy support generating HTML files? I use Hugo for a
           | few websites that I host on S3 + CloudFront and am very happy
           | with AWS handling the back-end part this stack, and wouldn't
           | want to switch to a server that I would now need to manage.
        
             | francislavoie wrote:
             | Caddy doesn't emit static files in this case, instead it
             | on-the-fly transforms your .md files on disk into HTML
             | output that it serves directly to the client. Caddy is a
             | server first, which includes a template engine for
             | convenience.
             | 
             | If your workflow with static files cached by a CDN already
             | works for you, then this is probably not going to help you.
        
         | [deleted]
        
       | danrl wrote:
       | I always liked Caddy for its simple config and automation around
       | TLS certificate management. I hope it doesn't go down the path of
       | feature bloat. Markdown rendering seems innocent enough, but what
       | will be next?
        
         | francislavoie wrote:
         | This is not new, it's been in Caddy for over 4 years.
         | 
         | Caddy is very modular by design, so anyone can write plugins to
         | augment its capabilities. The "templates" directive is in the
         | standard distribution, because it's simple and generally
         | useful.
        
       | rcarmo wrote:
       | I would argue against this being "static" in the pure sense of
       | the word (since Caddy is still going to parse the markup, etc.),
       | but it is an extremely neat trick.
        
       | Simon_O_Rourke wrote:
       | Fantastic idea, I needed something like this last year to
       | generate a coding blog from markdown.
       | 
       | What's your take on code formatting and syntax highlighting?
       | 
       | I only ask as I got so frustrated installing and using Jekyll on
       | Azure that I ended up rolling my own markdown-to-webpage script
       | that would format code snippets nicely.
       | 
       | There's a definitely gap in the market for something that's not
       | quite WordPress, but better than Jekyll. Would be interested to
       | see what you think.
        
         | speg wrote:
         | I think so too. I had to roll my own (which was half the fun)
         | and slowly add new features as I go.
         | 
         | Compiled with Crystal-lang and SQLite; you just drop in a
         | single binary and away you go.
        
         | Proven wrote:
        
         | Loic wrote:
         | Directly went to look at the source.
         | 
         | What is really really nice, is that the _templates_ [0] is
         | written as a Caddy module. It means that you should be able to
         | "clone" and extend it easily to experiment with _complex_
         | modules.
         | 
         | You could definitely use it as a basis to have your CMS based
         | on this module.
         | 
         | [0]:
         | https://github.com/caddyserver/caddy/tree/master/modules/cad...
        
       | EGreg wrote:
       | I thought about it. Why do you even need static site generators
       | when all you have to do is throw up a CDN with your dynamic site
       | being the origin server? Same thing pretty much as the static
       | site generator. You can even "generate" the static pages by
       | visiting them yourself.
       | 
       | Oh yeah, and when something on a page changes, you tell the cache
       | to invalidate some tags.
        
         | manigandham wrote:
         | There is some advantage in security, deployment is easier,
         | performance can be better if page generation is intensive, and
         | backend data stores can be avoided completely. None of these
         | are major reasons though and it's mostly just popular tech
         | stacks from the rise of javascript frameworks and UI.
         | 
         | Most static hosting providers are just a basic file/web server
         | with a CDN in front. It's especially interesting as they now
         | have come full circle with generate-on-demand pages, which is
         | basically a dynamic backend.
        
         | cprecioso wrote:
         | This is basically what Next.js does
         | https://nextjs.org/docs/basic-features/data-fetching/increme...
        
           | akagusu wrote:
           | This is basically what people used to do with server-side
           | frameworks long before the frontend framework SPA/SSG/SSR
           | craziness wiped out people's memories.
        
         | IshKebab wrote:
         | Because then you have to run a dynamic site. Static site hosts
         | are much easier to come by for free.
        
       | camkego wrote:
       | This is a cool article. Unfortunately the described syntax only
       | covers Caddy V1. Caddy has been on V2 since early 2020, and the
       | V1 examples won't work on V2 for markdown usage.
       | 
       | These links can help with Caddy V2 Markdown usage:
       | 
       | https://caddyserver.com/docs/caddyfile/directives/templates
       | 
       | https://github.com/caddyserver/website/blob/master/src/docs/...
       | 
       | https://caddy.community/t/markdown-support-in-v2/6984
       | 
       | Thanks to the Caddy team for such an excellent program!
        
       | smoyer wrote:
       | Wouldn't this more properly be classified as a static site
       | server?
        
         | capableweb wrote:
         | If you have one file format (markdown in this case) and
         | transforms it to another format (html and css in this case) on
         | every request, I wouldn't call it a static site (server)
         | anymore. I'd only call it a static site server if it serves
         | static files without modifications on request, and if you need
         | to generate those static files from other files, that process
         | is decoupled from incoming requests to the server.
        
           | Macha wrote:
           | I guess it's kind a spectrum:
           | 
           | 1. Wordpress in a default install, definitely not static
           | 
           | 2. Wordpress with a caching plugin, wherein the cache is
           | generated on request is only expired on page update. Still
           | not really static
           | 
           | 3. Wordpress with a caching plugin, where the cache is
           | created on page edit but still served by the PHP code
           | 
           | 4. Wordpress with a caching plugin, where the cache is
           | created on page edit but pushed to another server to serve
           | (i.e. using it as a headless CMS)
           | 
           | 5. Your standard markdown -> html static site tool
           | 
           | To me step 4 is when the resulting site crosses over to a
           | static site.
        
             | onionisafruit wrote:
             | 6. Write your pages in html and save them in ~/public/www
             | on your university's server.
        
       ___________________________________________________________________
       (page generated 2022-01-31 23:02 UTC)