Why I Built This Site With Lektor And Would I Recommend It?

This Site Runs on Lektor, Here's Why

When I built the new I had a few primary objectives:

  1. I wanted to keep costs as low as possible
  2. I didn’t want to run a server
  3. I didn’t want to avoid comment maintenance.
  4. I still wanted full control over the theming and content of the site.
  5. I needed robust, simple text backups for all content

I think the first one is pretty self-explanatory, I don’t know anyone who wants to keep their costs as high as possible. The next two spring from lessons learned from over a decade of running Wordpress and other PHP based CMS’s. Even with the low cost of Amazon, I didn’t want to take on the burden of constant security updates for an open Linux server hosting a website, and although Plesk based, shared hosting environments are wonderful, they still leave you open to a pretty large surface area for security and spam issues. The final point stems from a desire to preserve URLs over time. If I ever want to change the implementation of the site in the future, It was critical that my content existed in some external repository. Dumps of the underlying database or other complex export formats don’t work in my experience. In a perfect world, the content would consist solely of markdown or some other robust, easily parsed and transformed format.

I spent some time investigating alternative hosting solutions or even going with a shared publishing option like Medium. In all cases, the hosted solutions kept coming up short due to the tension between keeping costs down, long-term flexibility and the durability of my data.

Eventually, I came to the idea of a static content delivery system. Content would be stored in plain text in the source of the site and committed into git for durability. I also would leverage a simple file format, so changing to a different platform wouldn’t be a painful exercise in the future. Jekyll was an obvious potential choice. I also explored Hexo, Hugo, and Pelican. Eventually, I settled on Lektor. My daily driver programming language is Python most days, which makes me partial to a python based solution like Lektor or Pelican instead of a Javascript or Ruby implementation. Lektor also had the benefit of a GUI editor and staging server that makes life a fair bit easier with content development. The deciding factor, however, was Lektor’s strong support for custom content types.

Mostly, the workflow for this site is as follows. I write the original content in Evernote, from whatever device I happen to have handy. I then cut and paste this content into Lektor running on my office desktop, set up all of the metadata and preview the content locally. I then check the resulting files into git and publish the site to s3. I host the entire site in s3 and distribute content via CloudFront. Total cost is about $ .30 per month.

Half a year later, I’m relatively happy with my decision. That’s not to say everything is roses. Lektor has worked well for creating the primary site. Building out the templates has been a learning curve, and I still don’t have a functional AMP implementation. Perhaps the biggest drawback is the complete lack of interactivity in the setup. Not supporting comments is nice, but having no feedback system is a bit of a downer. I’m hoping to implement some contact form soon.

Overall, Lektor has been an excellent platform for the site. It’s simple, flexible and surprisingly user-friendly. It’s not something the average user can leverage to get up and running without some help, but an excellent platform for anyone with basic cloud & HTML skills.