How to keep it cheapest on AWS Amplify? hosting Jekyll

[888ba8]

Hi. I am wondering what the cheapest way is to host your Jekyll blog on AWS Amplify?

I currently have the following amplify.yml build file:

version: 0.1
frontend:
  phases:
    preBuild:
      commands:
        - bundle install --path vendor/bundle
    build:
      commands:
        - JEKYLL_ENV=production bundle exec jekyll b
  artifacts:
    baseDirectory: _site
    files:
      - '**/*'
  cache:
    paths:
      - 'vendor/**/*'

Is it even necessary to do the bundle install prebuild? I wonder if I can not just build the new versions on my file locally, then just only push the static site folder to AWS Amplify?

P.S.: I recently installed a new plug-in and because of the dependency which means that ImageMagick should be installed, AWS Amplify now won’t build and is giving me the following message: jekyll 3.9.0 | Error: You must have ImageMagick or GraphicsMagick installed

I don’t know how to fix this, but I am assuming fixing this would make everything more expensive, right? I presume it should be fixed somehow via the preBuild command? It just seems strange to keep running the same commands over and over again on Amplify, while I only push a new version from my home pc after I already built the static files locally? I can just build everything locally on my pc right?

Or would it even be possible to ‘include’ ImageMagick to AWS Amplify via CDN?

[AlfredoRamos]

@888ba8

Hi. I am wondering what the cheapest way is to host your Jekyll blog on AWS Amplify?

Is there a specific reason to use AWS Amplify?

It’s only curiosity, because you could host it for free (really free) using GitHub Pages, Netifly or even CloudFlare Pages, I’m not sure about this last one though.

@888ba8

Is it even necessary to do the bundle install prebuild?

Yes.

These kind of services (GitHub Actions, Travis CI, Nettifly, etc) give you a fresh VM each time it starts, however those services usually have a cache system, so even if you are running bundle install each time, those saved gems are used and updated as needed, so you do not consume a lot of build minutes.

@888ba8

I wonder if I can not just build the new versions on my file locally, then just only push the static site folder to AWS Amplify?

You could, I guess, but for me is easier to have it fully automated.

@888ba8

I don’t know how to fix this

Just install ImageMagick as the error says, similar to when you had to install it on your system.

@888ba8

Or would it even be possible to ‘include’ ImageMagick to AWS Amplify via CDN?

I’m not sure I understand that

You cannot “include” ImageMagick like you would do with CSS or JS files, but you could use a CDN to download and install the package in the system.

In fact that’s the way those kind of services install external dependencies.

[888ba8]

@AlfredoRamos

Is there a specific reason to use AWS Amplify?

It’s only curiosity, because you could host it for free (really free) using GitHub Pages, Netifly or even CloudFlare Pages, I’m not sure about this last one though.

HI @AlfredoRamos thanks a lot for your replies.

The reason to use AWS Amplify is that it has an easy GUI option to use authentication (username & password) on your whole ‘server’ (complete website locked and all included files). It uses Amazon Cognito behind the screens.

So I found AWS Amplify the preferred choice if you want some privacy on your files. Before that I was experimenting with GitHub Pages (not preferred, as your repository itself can not be private in free mode) and Netlify (I was using staticrypt to encrypt all HTML files with a password, which worked great, but if anyone knew the URL of the other non-HTML files on the server, they would be able to just get away with them … … the robots.txt could be bypassed to get the other files …so not really preferred for sensitive data you want password-protected. Also the HTML files could be downloaded locally and brute-force attacks would eventually reveal the password, theoretically).

So I am now using GitLab instead of GitHub. Since GitLab allows free users to have private repositories not accessible to the rest of the internet. And as explained, on top of that AWS Amplify to password-protect the actual complete website and files.

I haven’t looked much in to Heroku, Travis CI, I have no experience with them.

@AlfredoRamos

These kind of services (GitHub Actions, Travis CI, Nettifly, etc) give you a fresh VM each time it starts, however those services usually have a cache system, so even if you are running bundle install each time, those saved gems are used and updated as needed, so you do not consume a lot of build minutes.

Does it mean that the installed gems stay cached and accessible for the next build? Or does it also mean that the static files that were generate last time stay cached, and it is checked how much of a change, if any, each file has been updated/added/removed versus last build/push?

I am using GitHub Desktop to upload my whole Jekyll directory each time to AWS Amplify, so it only pushes those files which are updated, I believe. So, in my eyes, that seems efficient. However, in my understanding, if AWS Amplify would completely rebuild the whole website, even if only one or two files had been changed/pushed/updated via the previous GitHub Desktop step, it seems terribly inefficient.

Would you be able to give me some advice on how to only push/update the static website files on AWS Amplify whenever I make a new push (i.e. the site folder, I believe)? I am hoping it would stay cheaper.

• P.S. / aftertought: Perhaps this “only upload the site folder” road is no good? I don’t have enough understanding, but just now as a testing step, I copied my site folder locally, and I opened it in a web browser, and already several images were missing and links broken (missing local file path prepended), search is not finding any hits,… Perhaps the broken links have got something to do with @MichaelCurrin’s comment here:

@MichaelCurrin

Yes the code by author is wrong and you should fix it. Removing a forward slash on most URLs anywhere in the URL (ie beginning and middle and end) is very weird and not something that Jekyll sites do.

---

---

@AlfredoRamos

Just install ImageMagick as the error says, similar to when you had to install it on your system.

In the mean time I will try this route.

@AlfredoRamos

You could install ImageMagic before running bundle install , so the installation of that gem can continue.

I haven’t used AWS Amplify, but I believe you can use yum or dnf to install ImageMagick.

In the mean time I will try this route. I find a lot of tutorials on the internet on how to install ImageMagick on AWS Lambda, but not on AWS Amplify. Strange. I hypothesize most people who want to customise stuff that far, might have the knowhow to use a generic EC2 instance on AWS, but I don’t have that far of a knowledge, so feel more comfortable with the WYSIWYG GUI AWS Amplify for now.

[MichaelCurrin]

Do you know about Netlify’s password protection?

You can add a password across your site or a path using this

Secure access to sites

If you want to invite users who each have a password, you can use Netlify Identity.

I’ve used that before for inviting a user from in Netlify to be admin/editor CMS user. It looks like that same system can be extended to control users with view access to the site. Using JSON Web Tokens

Role-based access control with JWT

When you use an authentication provider that supports JWT, your site visitors log in to your site using the provider service, and the service returns an encrypted JWT with user data.

[888ba8]

@MichaelCurrin

Do you know about Netlify’s password protection?

@MichaelCurrin However, I understand this is not a free option, unfortunately.

For now, I do not have a budget available, but am lucky to have a lot of AWS credits to use this year, and I feel it is a nice way to slowly learn a bit more about these giants.

[MichaelCurrin]

Oh yes you’re right. The password and access control options on the pricing page is for pro only

[AlfredoRamos]

I see, AWS Amplify sounds interesting.

@888ba8

Does it mean that the installed gems stay cached and accessible for the next build?

Yes.

Usually the cache restores previously stored files before any installation, then during installation it will recognize that those gems are already there.

It will install missing gems if you add a new one in the Gemfile, or update if it needs to.

New gems (newly installed or updated) will be saved for the next build.

@888ba8

Or does it also mean that the static files that were generate last time stay cached

I was referring to the gems, but some services allow you to cache custom directories.

I wouldn’t recommend to cache the generated files from the _site directory, because you might store stale files. But if it works for you, it’s totally fine

@888ba8

Would you be able to give me some advice on how to only push/update the static website files on AWS Amplify whenever I make a new push (i.e. the site folder, I believe)?

Some tools from AWS have a CLI version. Maybe you could use it (if available) to upload the generated files.

But I’m just guessing, I might need to try Ampliy first.

[888ba8]

@AlfredoRamos

I see, AWS Amplify sounds interesting.

I believe the Microsoft alternative would be Azure Static Web Apps or Azure Active Directory, I am not sure. I don’t have any experience.